Ph. Marek wrote:
> On Mittwoch, 4. Juli 2007, Branko Čibej wrote:
>
>> Ph. Marek wrote:
>>
>>> To this I'd like to mention that the *technical* aspect of "just a
>>> directory structure" is one of the most valuable design choices in
>>> subversion (IMHO, at least).
>>>
>> Why? I'm really interested: What, exactly, do you (we) gain by that?
>>
> - Extensible
> - Versatile
> Eg. you can easily do some debian-like naming "experimental",
> "unstable", "testing", "stable" and merge in this directions.
> - Easily understandable to anyone who knows directories/folders
> (At least, if not the "old" understanding of CVS' tags/branches as a
> new dimension is present).
> I think that this point is *the* point for new users.
> - As soon as the information "Make pointer to old data" is given, all
> implications follow naturally.
>
Users new to the concept of version control will have trouble
understanding branches no matter how they're presented in the UI. 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.
>> 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. The moment
you allow free-form project structuring, and multiple project (with
different structures) in the same repository ... you get a combinatorial
explosion.
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 (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. I've seen so
many broken repositories where the breakage can be traced directly to
that assumption that it's not even funny.
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 -- 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.
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.)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 4 21:39:23 2007