[Dev] Subversion directory structuring

[John Anderson]

+1

Alec Flett wrote:
> Heikki Toivonen wrote:
>> where we put in the CVS tags into tags directory and CVS branches into
>> the branches directory. Now, svn strictly speaking does not support
>> tags. (Tags are supposed to be static, and never change.) But the way we
>> did the cvs to svn conversion we emulated tags with the tags directory.
>>   
> Personally I think tags (along with the actual term "tag") are just an 
> artifact of CVS - they covered the need in CVS to designate one frozen 
> point in time across files which each had their own version number, 
> and those tags were immovable to simulate the notion of a particular 
> set of versions being read-only.
>
> In SVN, those frozen points in time are more or less the same thing as 
> branches. Its true we don't want anything changing in the 0.6.1 
> directory after the release, but perhaps subversion offers something 
> more specific to subversion, like locking down a directory?
>
> It seems like maintaining a "tags" directory is a device to maintain a 
> legacy notion of version control, rather than accomplish the real goal 
> of locking down a particular branch.
>
> Alec
>
>
>> Many other projects work like this, for example Twisted. I think we
>> should do so as well.
>>
>> The way I think of branches is something that changes, like the trunk.
>> So, I would expect we'd have the 0.6 branch from which we take a
>> snapshot into the 0.6 tag, and again into 0.6.1 tag and so on. In other
>> words, the 0.6 branch continues to live on and checkins for the 0.6
>> series can happen there. An image might clarify:
>>
>>
>>            /---0.6 branch-*-*->
>> ----trunk------------------------>
>>
>> (we'd copy 0.6 and 0.6.1 from the * points into the tags directory). In
>> some rare cases we might branch from the branch, for example if we
>> expected 0.6.1.1 and 0.6.0.1. (We could create a 0.6.1 branch from the
>> 0.6.1 tag, so we could avoid a new branch unless we actually needed it.)
>>
>>
>> Some people have complained that they don't want to see many branches or
>> tags, and would like us to either delete old stuff or move them into
>> some archives. I think both of these would be bad ideas because we have
>> documentation pointing people on how to pull from a certain branch or
>> tag - if we change something these are going to break.
>>
>> My preference would be to just put all branches directly into the
>> branches dir and all tags directly into the tags dir.
>>
>> I don't see a problem with too many branches or tags, but if we must do
>> something I would suggest a scheme where locations, once created, never
>> change. So perhaps something like:
>>
>>   /branches
>>     /0.6-branches
>>   /tags
>>     /0.6-tags
>>
>> Where all the branches we create during 0.6 development cycle go into
>> the 0.6-branches, and all the tags into the 0.6-tags.
>>
>>   
>> ------------------------------------------------------------------------
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/dev
>>   
>
> ------------------------------------------------------------------------
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/dev/attachments/20060222/af3177a8/attachment.html