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

Re: Limitation of Undoing: Dataloss

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 29 Dec 2008 16:15:11 +0100

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]list.jan.hendrik_at_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_at_subversion.tigris.org].
Received on 2008-12-29 16:16:28 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.