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

[BUG] 'svn mv --force', 'svn ci' moves but doesn't commit local modifications

From: Daniel Rall <dlr_at_collab.net>
Date: 2006-01-31 22:57:53 CET

This bug results in transfer of the wrong content from client to
server, and a subsequent mismatch between WC and repository content.
This bug can result in data loss.

I thought Madan reported this problem late last year (when we
previously were both bitten by it), but I didn't notice anything
related in the archive, so here goes (again)...

Steps to reproduce:
===================
Modify a file in your working copy. Using Subversion trunk, 'svn
rename --force' the locally modified file, then 'svn commit' both WC
resources in a single operation. (Shell script reproduction recipe
attached.)

Observed behavior:
==================
The file's "base" version is sent to the server during the commit,
rather than the "working" version one would expect. Here's the output
of the attached reproduction recipe:

  $ ./recipe.sh
  Setup a basic WC.
  Checked out revision 0.
  A wc1/file.orig
  Adding wc1/file.orig
  Transmitting file data .
  Committed revision 1.
  
  Get a secondary WC
  A wc2/file.orig
  Checked out revision 1.
  
  Modify the contents of a file in the WC
  A wc1/file.new
  D wc1/file.orig
  Adding wc1/file.new
  Deleting wc1/file.orig
  
  Committed revision 2.
  
  Update the secondary WC, and examine the content of the file.new
  D wc2/file.orig
  A wc2/file.new
  Updated to revision 2.
  'svn info' says file.new should be identical in both WCs...
  --- wc1/file.new 2006-01-31 13:39:09.000000000 -0800
  +++ wc2/file.new 2006-01-31 13:39:11.000000000 -0800
  @@ -1,2 +1 @@
   foo
  -bar
  ...but it is not! "bar" is absent from both wc2/file.new, because
  it was never actually committed to the repository. wc1 does
  not report this, and thinks that it's correct and up to date!

'svn ci' is sending the content of "base" rather than "working". This
may have something to do with the way the 'add' portion of the
'rename' implementation schedules its later work, or carries out the
execution of that scheduling during the subsequent 'commit'.

Expected behavior:
==================
The file's "working" version should be sent to the server during the
commit, rather than the "base" version that is being sent. Even if
there is disagreement WRT to this behavior (there was none on
#svn-dev), the WC from which the commit was made must not contain a
different version of the file than what's sent to the repository (and
subsequently pulled down into other WCs).

-- 
Daniel Rall


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Received on Tue Jan 31 22:58:46 2006

This is an archived mail posted to the Subversion Dev mailing list.