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

Re: Alphe-checklist comments

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2001-04-18 05:58:38 CEST

Branko =?ISO-8859-2?Q?=C8ibej?= <brane@xbc.nu> writes:
> I'm a bit worried about this idea. We may very well talk about
> educating the public; but first, we must know what we're talking
> about. I won't go so far as to say that this model is
> counter-intuitive, but it's definitely a lot different from what I,
> and probably most of us, are used to. So:
> - How certain can we be that exposing the implementation of tags and
> branches like this will really be easy for users to understand?
> It's taken me long enough to grok what JimB was getting at, for one
> thing. :-)

Our comrades at Collabnet understood us when we said "we make cheap
copies. You work in the copy, then merge the copy into another
directory. This is equivalent to a branch. If you don't touch the
copy at all, it's equivalent to a tag." There were no questions or
confusions about this.

Similarly, when Karl explained this in front of 150 linux users at the
SVLUG presentation, again, there were no questions or screams of
shock. People seemed to understand.

I think this bodes well -- we don't want to have to hide the
implementation at the outset. If we discover that these two above
events were anomalies, and that in fact most people *can't* understand
the "cheap copy" idea, then we can always cover it up later with our
client. However, if we start off by sugar-coating, we can never
remove the sugar-coating later without causing an upset. Better to
gradually work our way toward sugar-coating only we discover it's
absolutely necessary.

> - We'll have to offer a simple, foolproof directory layout for
> storing tags and branches. Can we do that without actually using
> SVN for a reasonable amount of time on a large project? (Note: SVN
> itself is not a large project (yet), nor has it been around for a
> reasonable time.) Don't forget that whatever we come up with must be
> flexible enough for cvs2svn to use, too.

Again, who are we to dictate policy? Our user documentation may
*recommend* a repository layout. Our friendly installation script may
offer to initialize a repository with some helpful top-level
tag/branch organizational directories, but it's only an option.

Remember: directories that are "cheap copies" can be moved and
juggled about however you wish. Halfway through a project, people can
suddenly decide to move all tag-directories into a single folder
called "myproject/tags/". Or maybe they'll want to rearrange them in
some different way. There's no need to force One Policy on the
world. Dirs are dirs -- let each project reorganize them as they want

(As for cvs2svn -- it can outright decide to create top-level 'tags'
and 'branches' subdirs, and place whatever it finds in there. After
the svn repository is completely built, administrators can move dirs
around at will.)
Received on Sat Oct 21 14:36:29 2006

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