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

[Daniel Rall <dl...@collab.net>]

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

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

["Peter N. Lundblad" <pe...@famlundblad.se>]

On Tue, 31 Jan 2006, Philip Martin wrote:

> Daniel Rall <dl...@collab.net> writes:
>
> > cd /tmp/
> > rm -rf repos wc1 wc2
> > echo 'Setup a basic WC.'
> > svnadmin create repos
> > svn co file:///tmp/repos wc1
> > echo 'foo' > wc1/file.orig
> > svn add wc1/file.orig
> > svn ci -m 'Adding new file.' wc1/file.orig
> > echo
> >
> > echo 'Get a secondary WC'
> > svn co file:///tmp/repos wc2
> > # Now both WCs contain the file w/ same content.
> > echo
> >
> > echo 'Modify the contents of a file in the WC'
> > echo 'bar' >> wc1/file.orig
> > svn mv --force wc1/file.orig wc1/file.new
>
> It's a timestamp bug in mv/copy -- the text-time in the entries file
> erroneously matches the working file and so the local mod is not
> detected.  If you manually "break" the timestamp
>
> touch wc1/file.new
>
> then the correct file contents get committed.
>
Seems like a regression of mine when I factored out
svn_wc_add_repos_file().

Will look at this ASAP.

Thanks,
//Peter

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

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

[Philip Martin <ph...@codematters.co.uk>]

Daniel Rall <dl...@collab.net> writes:

> cd /tmp/
> rm -rf repos wc1 wc2
> echo 'Setup a basic WC.'
> svnadmin create repos
> svn co file:///tmp/repos wc1
> echo 'foo' > wc1/file.orig
> svn add wc1/file.orig
> svn ci -m 'Adding new file.' wc1/file.orig
> echo
>
> echo 'Get a secondary WC'
> svn co file:///tmp/repos wc2
> # Now both WCs contain the file w/ same content.
> echo
>
> echo 'Modify the contents of a file in the WC'
> echo 'bar' >> wc1/file.orig
> svn mv --force wc1/file.orig wc1/file.new

It's a timestamp bug in mv/copy -- the text-time in the entries file
erroneously matches the working file and so the local mod is not
detected.  If you manually "break" the timestamp

touch wc1/file.new

then the correct file contents get committed.

> svn ci -m 'Renaming file w/ additional content.' wc1/file.new wc1/file.orig
> # wc1/file.orig is now gone, and wc1/file.new contains the new content
> echo
>
> echo 'Update the secondary WC, and examine the content of the file.new'
> svn up wc2
> echo "'svn info' says file.new should be identical in both WCs..."
> diff -u wc1/file.new wc2/file.new
> echo '...but it is not!  "bar" is absent from both wc2/file.new, because'
> echo 'it was never actually committed to the repository.  wc1 does'
> echo "not report this, and thinks that it's correct and up to date!"

-- 
Philip Martin

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