On 8/12/05, Branko Èibej <brane@xbc.nu> wrote:> Thomas Beale wrote:> > > Branko Èibej wrote:> >> >> David Weintraub wrote:> >>> >>> So, it seems rather strange that Subversion doesn't understand the> >>> built in concepts of branches and tags. Instead, these items are> >>> merely emulated via pseudo-directories. After all, tags and branches> >>> have been implemented as part of version control systems since RCS> >>> back in 1985.> >>>> >>>> >> Subversion certainly does understand branches and tags. The important> >> feature of branches (and tags -- these are just branches that are> >> never changed after creation) is that they establish a (named)> >> parallel line of development that tracks its ancestry and can expose> >> ancestry information to procedures that need it, e.g., merge.> >>> >> From what I've been able to gather from this thread, people are> >> either upset or confused because directories and branches share the> >> same namespace, whilst most other VC systems in use today have a> >> separate nam
espace for branches.> >> >> > I don't think anyone is upset or confused. Without wishing to> > antagonise anyone in this discussion, it is quite clear in a formal> > sense that subversion doesn't directly implement the semantics of> > branches and tags; it just approximates them using an existing> > facility. To see that this is true, consider that the concept of a> > 'tag' is not itself a 'parallel branch'; it is the name attached to a> > particular revision of a line of development, either the mainline, or> > some other branch. But it is not implemented in this way - it is> > implemented as a copy of some other part of the repository.> > *Sigh*> > You're imposing your fairly narrow perception of what tags are. A tag is> a name for a collection of versions (a configuration in SCM-speak).> Those versions can all come from one branch, but that's not a> requirement in general. How it's implemented, and what the name looks> like (in SVN's case, it's an URL), is irrelevant here. And, BTW, in> Subversion you can
create a tag that does not correspond to any> committed revision in the repository.
The concept that you keep missing is that tags and branches have aspecial relationship to the files they tag and branch from. Whatevermechanism is used to track branches and tags needs to know that theversion of "foo.c" that has the tag "BARFOO" on it, and that theversions of foo.c on the branch "foobar" are all related to theversions of "foo.c" sitting on my main trunk.
The truth is that Subversion simply doesn't understand thisrelationship. This is what is making things difficult in Subversion.Instead of my version control system tracking this, I now have to usemy poor overworked brain to do this type of stuff.
I don't really care about the underlying mechanism used to trackbranches and tags. It can be URLs, it can be copied directories, itcan be written on the 5x3 blue-lined index cards. That's up to thepeople who are far more apt at development than me to decide. I leftthe development field for CM almost two decades ago, and somehowsoftware is still getting developed without me writing a lick of code.
> Would you feel better if we had a "svn branch" and "svn tag" command?
Actually, that would be a step in the right direction. If their was a"svn branch" and "svn tag" command, that means that Subversion wouldhave a way of understanding that something is a tag or a branch andnot just a copy of a particular directory subtree to another area.
The next step would be for Subversion to use this information in a useful way.
For example, let's say I configure Subversion to use thehttp://myserver/myrepos/tags directory for my tags andhttp://myserver/myrepos/branches directory for my branches. In theorya command like:
$ svn tag REL1.0 .
Seems to be the equivelent of:
$ svn cp . http://myserver/myrepos/tags/REL1.0
but if Subversion would now actually understood that this is a specialobject called a "tag". I could now do something like this:
$ svn co -rREL1.0 http://myserver/myrepos/mydirectory .
And, Subversion would understand that I am really asking for the URLhttp://myserver/myrepos/tags/REL1.0/mydirectory. All I need to do isgive Subversion a label, and Subversion handles the rest. Even betterwould be something like this:
$ svn commit . -m "Attempting to check in a tagged Checkout"Error: You cannot commit from a working directory based upon a tag.
Nope, not allowed to modify the tag. Now, when I, as a CM want tobuild REL1.0 again, I can be absolutely sure of the sanctity of my tagand that no one changed it without me knowing about it. Okay, theirmight be times you want to modify a tag, so maybe require a "--force"parameter and have the concept of locking tags to prevent their changeeven with a "--force" parameter. Now, that would be cool.
Of course, now that Subversion understands what a tag is, I'd like todo this too:
$ svn diff -rREL1.0 foo.c
I am now diffing my copy of foo.c with the version tagged REL1.0 and Idon't have to know the URL.
Branches would be very similar:
$ svn branch rel1_bugfixBranch "rel1_bugfix" was created from the current URL.
Again, under the surface, this could be equivelent of
$ svn cp http://myserver/myproj/trunk http:/myserver/myproj/branches/rel1_bugfix
but Subversion would have the concept that this is a branch and hassome special properties:
$ svn co -rrel1_bugfix http://myserver/myproj/mydir mydir
I'm checking out mydir, but I am working on the rel1_bugfix branch Icreated. I don't have to know where the branch is stored, sinceSubversion knows it.
Of course since this is a branch and not a tag, I should be able tocheck in changes:
$ svn commit -m "This is work on a branch"created revision 655 on branch rel1_bugfix
Yup, created a new revision of the archive, but also gave me the nameof the branch to remind me that I'm not working directly on the trunk.
And, just like tags, I could take a diff between the version in mycurrent working directory and what is on a particular branch withouthaving to know the details where Subversion stored it:
$ svn diff -rrel1_bugfix foo.c
Of course, the most important thing of all in working with branches is merging:
$svn merge -rrel1_bugfix .
That would automatically merge all of the changes from my rel1_bugfixbranch to my current working directory. Since Subversion understandsthe concept of a branch, it could then easily track what versions ofthe code on the rel1_bugfix branch were previously merged intowhatever branch is in my current working directory. Now, I have tomanually track merges, where merging occured, what happened, etc.
The problem really isn't that Subversion can't track branches andtags. I also implemented tags and branches as copies (literally theUnix "cp" command) in my version control system. The problem is thatSubversion doesn't understand that these tags and branches havespecial meaning to me, and should respond appropriately.
--David Weintraubqazwart@gmail.com
Received on Fri Aug 12 21:25:32 2005