kfogel@collab.net wrote:
> Daniel Patterson <danpat@danpat.net> writes:
>
>> Just a note (and I'm not sure how helpful) on how Clearcase handles
>> this operation. For Clearcase, the rename of a file bumps
>> the version number of the containing directory, but not of the
>> item being renamed itself. This avoids the issue of having to
>> commit a change to the file itself (and the confusion about which
>> side the commit should happen to).
>
>
> Are you assuming that both src and dst are always in the same
> directory? That's not necessarily the case...
No, and this is kind of one of the areas that Clearcase's lack
of atomic commits is a bit of a pain.
If you do basically "cleartool mv file1 ../newdir", you can
get yourself in a bit of a poo. If you commit the source
directory, then the file is now missing in the repository.
If you only commit the dest directory, you now have two
copies of the same file in two places. This happens quite
a bit in our installation of Clearcase, particularly amoung
the less experienced developers.
It's much closer to regular filesystem semantics than how
Subversion works. Clearcase basically treats a rename as
an unlink() and link(), while bumping the versions of the
containing directories, with no guarantee that the unlink()
and link() happen in the same transaction.
I'm definetly not suggesting that Subversion should do it this
way. Just an FYI and a "here's how someone else implements this,
and here's the drawbacks to that approach".
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 22 02:52:08 2005