RE: early reflections on subversion methodology

 Here's a question:

Should the functionality that you say is lacking in Subversion be in
Subversion itself, or is it better implemented at a higher level, let's
call it a meta-version control layer that exists between Subversion and
the client.

Sure, an extra layer adds overhead, but it seems to me what is being
described here is workflow or development methodology, not just plain old
version control, which Subversion seems to do just fine. Does it matter
that a branch or a tag is a copy? Or is it the user view of that branch or
tag that is the determining factor?

Is this the reason why we see so many requests (myself included!) for
guidance on repository design?

I don't think behavior like that ought be regulated in the client, but
strictly enforced to clients, and therefore perhaps a layer on top of your
version control.

just my 2 cents.

-----Original Message-----
From: qazwart@gmail.com [mailto:qazwart@gmail.com]
Sent: Friday, July 29, 2005 1:15 PM
To: thomas@deepthought.com.au
Cc: users@subversion.tigris.org
Subject: Re: early reflections on subversion methodology

On 7/28/05, Thomas Beale <thomas@deepthought.com.au> wrote:
> It would be good if subversion a) supported a standard directory
> structure like this, and b) if the tools could hide these directories
> (at least on the client side) and instead show them as 'views' - i.e.
> the user would be in the mainline view, the branch-xyz view, the
> release-0.8 view and so on. I don't think it would be hard to do.

Let's see if I can clarify this. You're really saying is that one of the
problems with Subversion is that version common meta-data concepts like
tags and branches are merely represented as normal, ordinary, every day
directories and not as specialized concepts as found in almost every other
version control system on the market. It's not that you insist that these
directories must be named RELEASE, BRANCHES, TAGS, and TRUNK. It's just
that Subversion should recongnize them as meta-data concepts and not as
plain old directories.

If this is what you're saying, I agree with you. I also think this is a
problem with Subversion.

Although you can successfully represent tags and branches as directories,
the implementation is clumsy. Any command such as merging, taking a diff
between various versions, and even making branches and tags is awkward.

Here's an example, I create a branch called "new_features" where I am
doing work that is taking place off the main line development. In most
advanced CM software, creating that branch is fairly straight forward.
In Subversion, I am making a copy:

$ svn cp http://myproject/trunk http//myproject/branches/new_features
-m "Creating branch"

Okay, not too bad, but what if I did this:

$svn cp http://myproject/trunk/mydirectory/mysubdir/foo_stuff
http://myproject/branches/new_features -m "New Branch"

in order to save some typing later on.

There is nothing in Subversion that lets me know that the new_features
branch is only a copy of the "foo_stuff" directory. That's something I
have to manually track. Not only that, but what if I suddenly realize that
the http://myprojects/trunk/mydirectory/mysubdir/bar_stuff also needs to
be on this branch? In this case in Subversion, I'm in trouble.
However, in most other CM packages, a branch type is availible to all
files in the repository.

Merging and diffing are also excellent examples. In most CM packages, I
could easily take a diff between my current working directory and any
particular branch or tag by simply giving the branch or tag name.
Since the CM package tracks the relationship between the various branches
and tags and my current working directory for me..

Things are different in Subversion. In Subversion, I have to give the full
URL to that branch or tag since Subversion doesn't track it:

$ svn diff
http://myprojects/branches/new_features/mydirectory/mysubdir/bar_stuff/foo
.c

By the way, this may have been the reason why the user initially copied
http://myprojects/trunk/mydirectory/mysubdir/foo_stuff to
http://myprojects/branches/new_features to begin with even though that
"breaks" the concept of branches. That way, the user saves some typing
when doing diffs and merges.

Does Subversion not having these meta-data concepts built right in make it
unusable? Not at all. SCCS doesn't have tags, but I tracked what was in
each release by creating a "release file" that listed each file and the
SCCS version ID. SCCS, RCS, nor CVS track directory changes, but I did
that via a makefile.

However, not having these meta-data concepts built in, and easily
accessible makes training people to use Subversion and implementing
Subversion a bit harder. I am now forced to write hooks in order to keep
people from accidently modifying my tags. I have to write wrapper scripts
to make sure people are using the branches and tags directory the right
way. The bigger my project, and the less geeky my developers are, the more
problems I'm going to have.

Does this mean I hate Subversion, and I think it stinks, and it is
unusable? Not at all. There is a lot to like about Subversion and I can
see why it is so popular with many OpenSource and non OpenSource projects.

--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org