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

RE: Understanding move merge

From: <rassilon_at_lyra.org>
Date: 2003-01-22 23:26:57 CET

 From: Greg Ward [mailto:gward@mems-exchange.org]
 On 21 January 2003, Branko ??ibej said:
  Yes. Renaming a node should not affect its history.
 But I *like* to see a log entry saying Renamed from foo to
 bar or Moved from ../foo to here, even if no lines of
 content changed in that revision.
  The effect of a
  cp+rm is to create a new branch in the node's history (and
 remove an
  one); that is obviously wrong, because, under our model, a
 rename does
  not constitute a modification of the node, only a
 modification of its
  (old and new) parent directory. In simple terms, after an
 svn mv in
  a clean working copy, svn st should show one or two modified
  directories, but no modified files.
 Ahh, I understand your rationale for why a rename should not
 affect the history of the renamed object. I think you're
 putting purity ahead of practicality here. Renaming a file
 is an important event in its history, and IMHO worthy of logging.

No he's not acutally. Logging the action is important as well. Renames
should be an atomic action, and they should be logged as such. No rocket
science there. The really annoying part with renames is in the WC half
of the equation. The other half is making sure both parts of a move get
committed at once, and branch merge file rename handling that's
efficient on the WC.

  (Of course, the user would want to know that the file was moved, so
  svn st should show something for usability's sake; but
 what it shows
  should not be a modified state but a renamed state.
 That means yet
  another status letter, but perhaps not.)
 And here, you're putting practicality ahead of purity!

UIs are always fickle. :)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:07:20 2006

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.