Re: early reflections on subversion methodology

In SCCS, I tracked directories changes and tags by using makefiles. I
used SCCS for many years, and SCCS did a very good at tracking my
changes, so why did I switch to RCS when I learned that RCS was
available? Because RCS had a cleaner and better implementation. RCS
knew what tags were. RCS worked better with Makefiles. RCS's commands
were easier to remember.

And, why do I want to use Subversion when the files in our project was
already in RCS format? Because I like the fact that Subversion makes
commits atomic and automatically forces commit serialization - that
is, only one person at a time commits their changes. I like the fact
that I can use hooks to maintain the sanity of my archive, and that
hooks are executed only on the server side. No more worrying why a
hook isn't working for a particular user. I like the fact that
Subversion doesn't have locking checkouts, and that Subversion makes
sure users cannot check in any changes unless their working directory
is up to date.

Both SCCS and Subversion track archive changes, and both do a
reasonable job. Subversion is better than SCCS because it does a
better job making sure what I am versioning is worth versioning, and
easily allows me to fix any errors. I like Subversion.

It's just frustrating pointing out a key missing feature and being
told that it's not problem. CVS has the concept of meta-data for tags
and branches built in. Subversion, the replacement for CVS, does not.
Yes, you can track it via pseudo branches, but that doesn't make it a
solid implementation.

Since Subversion doesn't track branching information, doing a merge or
a diff operation means spending time running and parsing through "svn
log" outputs, figuring out what it means, and then typing fairly long
and complex URLs. Since Subversion doesn't track branching
information, the user is left attempting to figure out what has been
merged and has not been merged. Since Subversion doesn't track
branching information, the user must remember to add helpful hints to
their commit messages.

Since a tag is just a directory, the user must be careful not to
trample on the sanctity of tags. Since tags are just directories, it
is up to the user to verify that the tag wasn't changed since it was
created.

Yes, I could build a new shell on top of Subversion's structure to
handle that just like I use to build shell on top of SCCS to handle
tags, or on top of RCS and SCCS to handle tracking directory changes.
But, I'd like to get away from that.

I'm again not requesting a development life cycle tracking tool or a
neat GUI front end. (I hate GUIs). I simply want something that a user
who understands the basics of version control can use without worrying
about making mistakes or wondering how I implemented the shell on top
of the system.

One of the things I really like about Subversion is the fact i can
ignore how the user interacts with Subversion. I've been in situations
were I'm supporting over a hundred users and spent most of my time
fixing bugs on the client system implementation and very little as a
CM. I want to concentrate on my CM task and not worrying whether or
not someone did an improper merge or misused a tag that was created.

To me, the meta-data concept of tags and branches should be
implemented within the VCS. As far as I am concerned, Subversion can
continue storing branches and tags as pseudo-directories (why not? It
does work.) All I am really saying is that Subversion should recognize
that these pseudo-directories are in fact meta-data concerning the way
the archive is structured and to handle that data as appropriate for
version control purposes.

On 7/29/05, ed.wittmann@fiserv.com <ed.wittmann@fiserv.com> wrote:
> 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
>
>

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