[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: Branko Čibej <brane_at_xbc.nu>
Date: 2007-12-15 04:29:06 CET

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

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 15 04:29:33 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.