On Mittwoch, 4. Juli 2007, Branko Čibej wrote:
> Users new to the concept of version control will have trouble
> understanding branches no matter how they're presented in the UI.
Well, I have different experiences, but that's probably because of the small
number (and very likely homogenity) of samples ...
> The
> current model may make newbies happy (through they end up with an
> inefficient repository), but will give headaches to people who do
> understand version control.
Here I don't understand.
What is inefficient?
Why does it give headaches?
I always found the structure of a subversion repository very nice and elegant.
> >> Compared to all the real pain it's causing.
> >
> > What pain does it cause?
> > Make "tag:A" be a synonym for "$URL/tags/A", and if another layout is
> > present, require a "svn:layout" property in $URL.
> >
> > Then use "svn cp . tag:A", or "svn diff tag:1.1 tag:1.2" or whatever.
> > Similar for branches. Result? No visible difference to CVS (for the
> > user).
>
> In my experience, user interface tricks like that are just that: tricks.
> And they cost implementation time, and are hard to get right.
90% of life is finding the right tricks, to make life easier.
If there are simple, documented rules how this gets translated, it's easy to
use.
> The moment
> you allow free-form project structuring, and multiple project (with
> different structures) in the same repository ... you get a combinatorial
> explosion.
Then restrict the "tag" and "branch" commands to normalized structures.
Either people use the suggested directory hierarchy (or one of two examples),
and can use the full power of the tools, or they cook their own cake and have
to provide the ingredients.
> Another problem is that you can't really create a hierarchy of branches
> without playing tricks with branch naming. So we enforce a flat
> namespace on a concept where hierarchy is useful
But I thought that's exact the flexibility of subversion???
Just use
trunk/
tags/
branches/
branch-1/
trunk/
tags/
branches/
branch-1.1/
branch-1.2/
branch-2/
etc.
It's easily possible, and I got that idea about 15 seconds after reading your
lines (not that I never heard of hierarchical branches before, but they're
not in my primary thinking) - which I take as a point for subversions'
flexibility :-)
> (remember I'm talking
> about large, complex projects here, not relatively trivial ones like
> Subversion or GCC or KDE or ... heh). We actually made things worse than
> necessary in real life by proposing that infamous trunk/branches/tags
> structure -- because trunk is privileged compared to other branches,
> users tend to assume there's something special about trunk.
Hmmm, the users I know don't have that expectation, but there are certainly
some.
> I've seen so
> many broken repositories where the breakage can be traced directly to
> that assumption that it's not even funny.
Then don't create a trunk/ but a branches/devel or some such, and it's clear
that it's the same as other branches. trunk is just used more often, and a
shorter name is better Huffman coding.
> I might also mention a propensity among the new users that this
> conflated namespace allegedly helps to check out whole repositories --
> all branches, all tags, everything --
Well, you have more experience with users, I believe ... So you'll see a wider
spectrum.
> and create branches locally by
> literally doing a WC->WC svn copy; or even plain copy + add + commit,
> which happily tosses away history. Then you hear complaints about how
> slow Subversion is for creating tags and branches, and how much space it
> burns on your disk.
Then you say "read the documentation, creating branches in the repository",
and slap them behind the ears ;-)
No, I understand your worries.
But mis-use has been done with CVS too ... I remember having seen (and read) a
lot of stories how CVS is "bad", eg. because someone tagged *after every
single commit* to get what subversion has implicit - relations between the
files, to reconstruct some common base line.
There'll always be some users who don't read the documentation, read it and
forget it or do other than suggested because "it's more logical", only to
have problems later ...
That's one of the points where I say "subversion should give enough rope" :-)
> So, I submit:
>
> * New users are generally ignorant about branches and tags, and get
> confused by the extra cruft directories.
> * Knowledgeable users need far more expressive power than our model
> actually provides.
> * Any loss of flexibility is regained by allowing cross-repository
> merging (something that we need anyway if we allow local branches
> and off-line commits), and restrict to one "project" per repository.
>
> (Well, Multi-repository "views" in the working copy would be nice, but
> when every working copy is a repository, you effectively get those for
> free.)
I don't share your experiences, but I think you know what you're doing.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 5 08:28:45 2007