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

Re: Reality check

From: Roy Franz <roy.lists_at_gmail.com>
Date: 2007-12-18 04:37:13 CET

On Dec 14, 2007 7:29 PM, Branko ╚ibej <brane@xbc.nu> wrote:
> Karl Fogel wrote:
> > Branko ╚ibej <brane@xbc.nu> writes:
> >
> >> IMNSHO, we should first support the mainstream CM paradigm, then worry
> >> about edge cases such as yours. Having the branch and directory
> >> namespaces conflated is sexy for small projects but horror on
> >> moderate-sized ones. And on large projects, you end up inventing branch
> >> namespace hierarchy where the tool doesn't support it.
> >>
> >
> > I'm all for distinguishing formally between branches and copies, but
> > I'm not at all convinced it's problematic to have branches live in the
> > directory hierarchy. Kind of the opposite: I've liked it so far!
> >
> > This may be because I lack some important bit of experience. If so,
> > and if you have that experience, Branko, please share...
> >
> The second problem is semantics.
> It's not just about formally distinguishing between copies and branches.
> This goes deeper.
> I submit:
> * When you make a branch, you want all that merge-tracking machinery
> to kick in.
> * You want easy answers to questions like "what changed on this
> branch?" and "where did we branch from?" and so on.
> * When you make a copy, you may want to vaguely remember what you
> copied, but you don't want any merge tracking or history from
> beyond the point of copy.
> * The above is again different from a rename, which is abstractly
> almost like a copy and delete, except that you /do/ want all
> history ... the changes in the name of the object are
> coincidental. (Note how filesystems treat "move" and "copy" quite
> differently in terms of inode identity, ownership and access rights.)
> All of these are superficially UI issues, and we even support them in a
> way (remember --stop-on-copy?), but really more as afterthoughts. And we
> don't support tag semantics at all.
> -- Brane

I have to heartily agree with Brane, as the current paradigm has
caused us many headaches, and
I think than many developers here consider the move to SVN a
regression from CVS. Our biggest headaches have been with tags.
We often want to know what version of a specific file went into a
specific release (tag.) Even in the simple case
of the tag being made directly from trunk, this is very cumbersome,
and gets worse if if is made from a branch.
This used to be trivial in CVS, and this is a very visible regression
in usability.
Tools that draw revision graphs like tkCVS don't do the right thing in
SVN. (it takes some shortcuts to try draw the graph in SVN,
but fails in all but very simple cases.)

Any repository reorg makes these problems worse. Early on a user
deleted the 'tags' directory. No problem - just copy it from a
previous revision. This of course breaks tkCVS, adds another level of
indirection to find tagged revisions. We ended up doing a dump/load
skipping the revisions with the delete/copy to fix tkCVS. I think that
if some of these operations (delete tags, branches, copy from previous
revision) were done on the main SVN repository that there would be
more awareness of some of these problems.

I personally think that some of these basic usability issues are much
more important than offline operation, etc.

Received on Tue Dec 18 04:37:25 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.