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

Re: Stage 1 of true rename support.

From: Daniel Patterson <danpat_at_danpat.net>
Date: 2005-05-22 02:46:03 CEST

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".


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

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.