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