Rename: data loss

[Sindbad the Seafarer <si...@gmx.net>]

Hi all out there!

The scene:

wc1/file1 was changed (a paragraph added), not yet committed;

wc2/file1 was renamed in TSVN to renamedfile1 and then changed 
(renamedfile1 opened in editor and some existing paragraphs 
changed), then committed.

Now this happened:

On commit (with TSVN) of wc2 file1 was reported deleted and 
renamedfile1 added.

When wc1 was updated renamedfile1 was added to wc1 and file1 
reported deleted.

However, the paragraph added in wc1/file1 was not merged into 
renamedfile1 - it was lost! Obviously SVN did not kept track of the 
renaming process.

The curious thing, however, is that a search showed wc1/file1 was 
still present, with the added paragraph, without the changes made 
in wc2, despite the update process reported it as being deleted 
(and in wc2 it *is* deleted). But it was not under version control 
anymore.

SVN .27 (latest Windows installer), TSVN .16 (for one working 
copy depends on file:/// access, so TSVN could not be updated so 
far), Win2000, Apache 2.0.47.

Any hints or should concurrent change & rename not happen in 
real life?

TIA - Jan Hendrik

---------------------------------------
Freedom quote:

     As a man is said to have a right to his property,
     he may be equally said to have a property in his rights.
     Where an excess of power prevails,
     property of no sort is duly respected.
     No man is safe in his opinions, his person, his faculties,
     or his possessions.
                -- James Madison, National Gazzette, 1792

---------------------------------------
Mailed with Pegasus Mail 3.12c (32bit).
Never heard of it?
Easy to use, full featured - and freely available.
And *no* automatic virus activation and spreading.
Take a look at http://www.pmail.com
Give it a try - and you'll never miss anything else.

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

Re: Rename: data loss

[Ben Collins-Sussman <su...@collab.net>]

"Sindbad the Seafarer" <si...@gmx.net> writes:

> Perhaps I have to rethink our commit policy here. Dunno how this 
> is on programming, but with website production it seemed fine to 
> update in the morning and commit in the evening, with more cycles 
> only if there had been site-wide changes involving many files.

The rule of CVS (and SVN) is usually "update right before you commit".
Most of the time, the update won't be relevant.  Sometimes you may get
a merge or a conflict, which is better than watching your entire
commit get rejected.


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

Re: Rename: data loss

[Sindbad the Seafarer <si...@gmx.net>]

Concerning Re: Rename: data loss
Ben Collins-Sussman wrote on 8 Sep 2003, 7:34, at least in part:

> "Sindbad the Seafarer" <si...@gmx.net> writes:
> 
> > Now I only wonder what would have happened if wc1/file1 with the 
> > added paragraph had been already committed before 
> > wc2/renamedfile1? Would then the added paragraph in file1 had 
> > been merged into renamedfile1? (I simply have nothing around 
> > today to just try it.)
> 
> Well, the person doing the name would have a "copy" and "delete"
> scheduled in the their working copy.  When they try to commit, the
> 'delete' of file1 would fail, because their copy would be officially
> out-of-date (it doesn't have the added paragraph).
> 
> So in response, the 2nd user runs 'svn up'.  The receive a patch to
> the schedule-delete file.  At this point, they may have second
> thoughts about committing.  If they commit the "deletion and copy",
> they'll be committing the deletion of the "new" file1 text, whereas
> the copy will still be of the "old" file1.  So yah, a commit would
> result in the loss of the new paragraph.  
> 
> Again, in an ideal situation, 'svn up' should add the paragraph not to
> the schedule-delete file, but to the schedule-copy one.  But that
> won't happen until we have atomic move operations someday.

So for now the lesson is A) to commit often; B) to update just 
before doing such drastic things like renaming and deleting and 
then directly commit renamed/deleted files.

Though this cannot guarantee that such situations do not come up 
at all it can reduce the chance of them.

Perhaps I have to rethink our commit policy here. Dunno how this 
is on programming, but with website production it seemed fine to 
update in the morning and commit in the evening, with more cycles 
only if there had been site-wide changes involving many files.

Jan Hendrik

---------------------------------------
Freedom quote:

     Welfare's purpose should be to eliminate,
     as far as possible, the need for its own existence.
                -- Ronald Reagan, Los Angeles Times, January 7, 1970

---------------------------------------
Mailed with Pegasus Mail 3.12c (32bit).
Never heard of it?
Easy to use, full featured - and freely available.
And *no* automatic virus activation and spreading.
Take a look at http://www.pmail.com
Give it a try - and you'll never miss anything else.

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

Re: Rename: data loss

[Ben Collins-Sussman <su...@collab.net>]

"Sindbad the Seafarer" <si...@gmx.net> writes:

> Now I only wonder what would have happened if wc1/file1 with the 
> added paragraph had been already committed before 
> wc2/renamedfile1? Would then the added paragraph in file1 had 
> been merged into renamedfile1? (I simply have nothing around 
> today to just try it.)

Well, the person doing the name would have a "copy" and "delete"
scheduled in the their working copy.  When they try to commit, the
'delete' of file1 would fail, because their copy would be officially
out-of-date (it doesn't have the added paragraph).

So in response, the 2nd user runs 'svn up'.  The receive a patch to
the schedule-delete file.  At this point, they may have second
thoughts about committing.  If they commit the "deletion and copy",
they'll be committing the deletion of the "new" file1 text, whereas
the copy will still be of the "old" file1.  So yah, a commit would
result in the loss of the new paragraph.  

Again, in an ideal situation, 'svn up' should add the paragraph not to
the schedule-delete file, but to the schedule-copy one.  But that
won't happen until we have atomic move operations someday.

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

Re: Rename: data loss

[Sindbad the Seafarer <si...@gmx.net>]

Concerning Re: Rename: data loss
Ben Collins-Sussman wrote on 7 Sep 2003, 14:37, at least in part:

> "Sindbad the Seafarer" <si...@gmx.net> writes:
> 
> > The curious thing, however, is that a search showed wc1/file1 was
> > still present,
> 
> Yes, this is one of those "tree conflict" situations, specifically
> issue 1196 (which Sander is working on right now!)
> 
> The situation is:  you have a file that is locally modified, and 'svn
> up' tries do delete it.   This is exactly what happened to you.
> 
> At the moment, what happens is that your working file simply becomes
> unversioned.   It's still present, however.  So please don't say any
> data was lost... it wasn't.  :-)

Quite right, I found it (and I knew very well what data it was). But 
what you outline about obstructed update makes much sense. 
Otherwise the thought to be deleted file would have lived on without 
notice. Maybe one would have stumbled about it on the next 
commit with TSVN, but as likely it could have been selected for 
adding without second thought - there are days we add dozens of 
new files. I am trying to do this via a toolbar in the HTML editor, but 
images fall through this anyway. And with TSVN it is very 
convenient.

I must admit that I was deliberately driving it to this point as in our 
website production here it is something that, though not happening 
every day, is relatively likely to happen: I put an illustration into the 
page while the other does something significant like a price change 
that requires a new name for the file.

Now I only wonder what would have happened if wc1/file1 with the 
added paragraph had been already committed before 
wc2/renamedfile1? Would then the added paragraph in file1 had 
been merged into renamedfile1? (I simply have nothing around 
today to just try it.)

Jan Hendrik
---------------------------------------
Freedom quote:

     The right to be let alone is indeed the beginning of all freedom.
                -- Supreme Court Justice William O. Douglas

---------------------------------------
Mailed with Pegasus Mail 3.12c (32bit).
Never heard of it?
Easy to use, full featured - and freely available.
And *no* automatic virus activation and spreading.
Take a look at http://www.pmail.com
Give it a try - and you'll never miss anything else.

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

Re: Rename: data loss

[Ben Collins-Sussman <su...@collab.net>]

"Sindbad the Seafarer" <si...@gmx.net> writes:

> The curious thing, however, is that a search showed wc1/file1 was 
> still present,

Yes, this is one of those "tree conflict" situations, specifically
issue 1196 (which Sander is working on right now!)

The situation is:  you have a file that is locally modified, and 'svn
up' tries do delete it.   This is exactly what happened to you.

At the moment, what happens is that your working file simply becomes
unversioned.   It's still present, however.  So please don't say any
data was lost... it wasn't.  :-)

We're well aware that there are better ways to handle this.  The ideal
way is to do what you were hoping:  that your locally modified file
would actually get renamed.  But in svn 1.0, 'svn mv' really just 'svn
cp + svn rm'.  So until we get "true" atomic rename operations in svn
post-1.0, we can't do the ideal thing.

For issue 1196, Sander's going to change the behavior of 'svn up'.
Whenever it tries to delete something that's locally modified, it will
instead error with an 'obstructed update' error.  This parallels
existing behavior: an unversioned file can obstruct an addition, and a
modified file can obstruct a deletion.  When these things happen, the
user manually moves the obstructing file out of the way, and runs 'svn
up' again to continue.   This is better than the status quo, where the
user *may not realize* that the modified file became unversioned.



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