+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
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
