You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jan Hendrik <li...@gmail.com> on 2008/12/29 10:09:01 UTC
Limitation of Undoing: Dataloss
Hi,
just before Christmas I asked for confirmation of this behaviour, but
received no answer, due to the Holidays and my circumstantial
explanation. (And without any reply I cannot build on that post, but
have to start a new thread as Google censors all own postings.)
Meanwhile I worked it out on a test repository and it turned out
even worse than supposed:
create repository;
checkout working copy;
populate wc with files file1.txt, file2.txt, file3.txt, each with some
content;
add & commit above files (rev.1);
add folder newfolder to wc & commit (rev.2);
svn move file1.txt, file2.txt, file3.txt to newfolder;
svn commit (rev.3);
modify content of newfolder/file1.txt, newfolder/file2.txt,
newfolder/file3.txt;
commit (rev.4);
svn merge -r 3:2;
=>
file1.txt, file2.txt, file3.txt are resurrected fine in their state before
the move, newfolder/file1.txt, newfolder/file2.txt, newfolder/file3.txt
are removed.
BUT all changes done on the files while in newfolder are gone, too
=> DATALOSS!
I suppose I could now merge rev. 4 onto the resurrected files
somehow. But what a tedious task if there are a hundred files
involved, affected by many revisions between rename/move and
undoing rename/move.
Am I missing something here or should there be a warning that
undoing a rename/move undoes ALL other modifications on the
respective files since?
TIA
Jan Hendrik
---------------------------------------
Freedom quote:
In the end, we will remember not the words of our enemies,
but the silence of our friends.
-- Martin Luther King Jr.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=994915
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Limitation of Undoing: Dataloss
Posted by Jan Hendrik <li...@gmail.com>.
Concerning Re: Limitation of Undoing: Dataloss
Stefan Sperling wrote on 29 Dec 2008, 16:15, at least in part:
> On Mon, Dec 29, 2008 at 01:26:14PM +0100, B Smith-Mannschott wrote:
> >
> > On Mon, Dec 29, 2008 at 11:09 AM, Jan Hendrik
> > <[1...@gmail.com> wrote:
> >
> > create repository;
> > checkout working copy;
> > populate wc with files file1.txt, file2.txt, file3.txt, each with
> > some
> > content;
> > add & commit above files (rev.1);
> > add folder newfolder to wc & commit (rev.2);
> > svn move file1.txt, file2.txt, file3.txt to newfolder;
> > svn commit (rev.3);
> > modify content of newfolder/file1.txt, newfolder/file2.txt,
> > newfolder/file3.txt;
> > commit (rev.4);
> > svn merge -r 3:2;
> > =>
> > file1.txt, file2.txt, file3.txt are resurrected fine in their state
> > before
> > the move, newfolder/file1.txt, newfolder/file2.txt,
> > newfolder/file3.txt
> > are removed.
> > BUT all changes done on the files while in newfolder are gone, too
> > => DATALOSS!
>
> Well, it's still in the history, so it's not exactly LOSS in capital
> letters. But this can break builds and can be very annoying to fix,
> as you said below.
Sure, you're correct. For the average content maintainer trained for
regular daily SVN usage up to conflict dealing the data is gone,
however, particularly as he will notice only when he needs it,
maybe months after svn update had quietly removed the copy in
newfolder. Expect him digging in the history then! <G>
Re: Limitation of Undoing: Dataloss
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Dec 29, 2008 at 01:26:14PM +0100, B Smith-Mannschott wrote:
>
> On Mon, Dec 29, 2008 at 11:09 AM, Jan Hendrik
> <[1...@gmail.com> wrote:
>
> Hi,
> just before Christmas I asked for confirmation of this behaviour,
> but
> received no answer, due to the Holidays and my circumstantial
> explanation. (And without any reply I cannot build on that post,
> but
> have to start a new thread as Google censors all own postings.)
> Meanwhile I worked it out on a test repository and it turned out
> even worse than supposed:
> create repository;
> checkout working copy;
> populate wc with files file1.txt, file2.txt, file3.txt, each with
> some
> content;
> add & commit above files (rev.1);
> add folder newfolder to wc & commit (rev.2);
> svn move file1.txt, file2.txt, file3.txt to newfolder;
> svn commit (rev.3);
> modify content of newfolder/file1.txt, newfolder/file2.txt,
> newfolder/file3.txt;
> commit (rev.4);
> svn merge -r 3:2;
> =>
> file1.txt, file2.txt, file3.txt are resurrected fine in their state
> before
> the move, newfolder/file1.txt, newfolder/file2.txt,
> newfolder/file3.txt
> are removed.
> BUT all changes done on the files while in newfolder are gone, too
> => DATALOSS!
Well, it's still in the history, so it's not exactly LOSS in capital
letters. But this can break builds and can be very annoying to fix,
as you said below.
> I suppose I could now merge rev. 4 onto the resurrected files
> somehow. But what a tedious task if there are a hundred files
> involved, affected by many revisions between rename/move and
> undoing rename/move.
> Am I missing something here or should there be a warning that
> undoing a rename/move undoes ALL other modifications on the
> respective files since?
>
> What you're observing is a "tree conflict" of some flavor.
Yes, it is, absolutely.
It's an interesting case because it's a reverse merge from the
history of the same branch. We were usually looking at merges
across branches. But I see no reason why the implementation we
have in trunk now should not handle this.
> Improved
> handling of tree conflicts is currently being worked on.
It's already in trunk and is supposed to be usable.
By all means, please test it if you can and let us know
what you think. You'll get it in 1.6 eventually, but if you
test it right now, we might be able to shake out bugs or issues
with the user interface sooner rather than later.
And even if you don't find anything wrong, that's great :)
Honestly, this kind of testing is really important and helps
Subversion a great deal. It's a great way to contribute.
> There's
> documentation of the issues in the subversion repository:
> [2]http://svn.collab.net/repos/svn/trunk/notes/tree-conflicts
> Google found me a presentation from Stefan Sperling which introduces
> the topic using subversion and mercurial as examples:
> [3]http://www.inf.fu-berlin.de/inst/ag-se/teaching/S-BSE/112_sperling_
> tree-conflict-handling.pdf
That is the introductory presentation I did for my thesis.
The final presentation has more up-to-date information:
http://www.inf.fu-berlin.de/inst/ag-se/teaching/S-BSE/121_sperling_tree-conflict-handling-thesis.pdf
So does the paper itself:
https://www.mi.fu-berlin.de/wiki/pub/SE/ThesesHome/thesis-tree-conflicts.pdf
It also contains figures and tables shown in the presentation and explains
them. The slides I used in the presentation don't explain them, I did that
on the fly.
Note that both of the above only talk about Subversion 1.5.
See also this presentation at Subconf by Stephen Butler and myself:
http://www.subconf.de/fileadmin/PDF_Dateien/SubConf/SubConf_2008/Vortraege/Stephen_Butler_und_Stefan_Sperling.pdf
and this one by Nico Schellingerhout:
http://www.subconf.de/fileadmin/PDF_Dateien/SubConf/SubConf_2008/Vortraege/Nico_Schellingerhout1.pdf
Unfortunately, the tree conflicts feature in its current implementation
lacks documentation (but the above links are still largely applicable,
from the user's point of view it's mostly command line client output
that's changed).
I am planning to extend the svnbook during the first week of January
to cover tree conflicts. No idea how much I'll get done though.
If you have time to play with this feature, please let me know what
you think. It helps to see things from the user's point of view,
especially when writing documentation. If you have any questions,
just ask (don't forget to Cc this list). While answering questions
about this feature I can take notes for the book.
Thanks,
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=995106
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Limitation of Undoing: Dataloss
Posted by B Smith-Mannschott <bs...@gmail.com>.
On Mon, Dec 29, 2008 at 11:09 AM, Jan Hendrik <li...@gmail.com>wrote:
> Hi,
>
> just before Christmas I asked for confirmation of this behaviour, but
> received no answer, due to the Holidays and my circumstantial
> explanation. (And without any reply I cannot build on that post, but
> have to start a new thread as Google censors all own postings.)
> Meanwhile I worked it out on a test repository and it turned out
> even worse than supposed:
>
> create repository;
> checkout working copy;
> populate wc with files file1.txt, file2.txt, file3.txt, each with some
> content;
> add & commit above files (rev.1);
> add folder newfolder to wc & commit (rev.2);
> svn move file1.txt, file2.txt, file3.txt to newfolder;
> svn commit (rev.3);
> modify content of newfolder/file1.txt, newfolder/file2.txt,
> newfolder/file3.txt;
> commit (rev.4);
> svn merge -r 3:2;
>
> =>
>
> file1.txt, file2.txt, file3.txt are resurrected fine in their state before
> the move, newfolder/file1.txt, newfolder/file2.txt, newfolder/file3.txt
> are removed.
>
> BUT all changes done on the files while in newfolder are gone, too
> => DATALOSS!
>
> I suppose I could now merge rev. 4 onto the resurrected files
> somehow. But what a tedious task if there are a hundred files
> involved, affected by many revisions between rename/move and
> undoing rename/move.
>
> Am I missing something here or should there be a warning that
> undoing a rename/move undoes ALL other modifications on the
> respective files since?
>
>
What you're observing is a "tree conflict" of some flavor. Improved
handling of tree conflicts is currently being worked on. There's
documentation of the issues in the subversion repository:
http://svn.collab.net/repos/svn/trunk/notes/tree-conflicts
Google found me a presentation from Stefan Sperling which introduces the
topic using subversion and mercurial as examples:
http://www.inf.fu-berlin.de/inst/ag-se/teaching/S-BSE/112_sperling_tree-conflict-handling.pdf
// Ben Smith-Mannschott
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=994981
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].