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