[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: early reflections on subversion methodology

From: Monks, Peter <peter.monks_at_vignette.com>
Date: 2005-08-12 21:34:18 CEST

G'day David,

Some of what you're pointing out sounds like Subversion's current lack of merge tracking. If so, you might be pleased to know that the developers have been aware of this for some time, that it is on the roadmap [1] and that some preliminary analysis has been performed [2].

Cheers,
Peter

[1] http://subversion.tigris.org/roadmap.html
[2] http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt

----------------------------------------------------------------------
Peter Monks http://www.sydneyclimbing.com/
pmonks_at_sydneyclimbing.com http://www.geocities.com/yosemite/4455/
----------------------------------------------------------------------

From: David Weintraub
Sent: Fri 12-Aug-05 12:22 pm
To: users@subversion.tigris.org
Cc: Thomas Beale
Subject: Re: early reflections on subversion methodology

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 namespace 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 a
special relationship to the files they tag and branch from. Whatever
mechanism is used to track branches and tags needs to know that the
version of "foo.c" that has the tag "BARFOO" on it, and that the
versions of foo.c on the branch "foobar" are all related to the
versions of "foo.c" sitting on my main trunk.

The truth is that Subversion simply doesn't understand this
relationship. This is what is making things difficult in Subversion.
Instead of my version control system tracking this, I now have to use
my poor overworked brain to do this type of stuff.

I don't really care about the underlying mechanism used to track
branches and tags. It can be URLs, it can be copied directories, it
can be written on the 5x3 blue-lined index cards. That's up to the
people who are far more apt at development than me to decide. I left
the development field for CM almost two decades ago, and somehow
software 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 would
have a way of understanding that something is a tag or a branch and
not 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 the
http://myserver/myrepos/tags directory for my tags and
http://myserver/myrepos/branches directory for my branches. In theory
a 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 special
object 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 URL
http://myserver/myrepos/tags/REL1.0/mydirectory. All I need to do is
give Subversion a label, and Subversion handles the rest. Even better
would 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 to
build REL1.0 again, I can be absolutely sure of the sanctity of my tag
and that no one changed it without me knowing about it. Okay, their
might be times you want to modify a tag, so maybe require a "--force"
parameter and have the concept of locking tags to prevent their change
even with a "--force" parameter. Now, that would be cool.

Of course, now that Subversion understands what a tag is, I'd like to
do this too:

$ svn diff -rREL1.0 foo.c

I am now diffing my copy of foo.c with the version tagged REL1.0 and I
don't have to know the URL.

Branches would be very similar:

$ svn branch rel1_bugfix
Branch "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 has
some 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 I
created. I don't have to know where the branch is stored, since
Subversion knows it.

Of course since this is a branch and not a tag, I should be able to
check 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 name
of 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 my
current working directory and what is on a particular branch without
having 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_bugfix
branch to my current working directory. Since Subversion understands
the concept of a branch, it could then easily track what versions of
the code on the rel1_bugfix branch were previously merged into
whatever branch is in my current working directory. Now, I have to
manually track merges, where merging occured, what happened, etc.

The problem really isn't that Subversion can't track branches and
tags. I also implemented tags and branches as copies (literally the
Unix "cp" command) in my version control system. The problem is that
Subversion doesn't understand that these tags and branches have
special meaning to me, and should respond appropriately.

--
David Weintraub
qazwart@gmail.com
Received on Fri Aug 12 21:35:25 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.