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]list.jan.hendrik_at_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>
From glancing over use-cases.txt I understand that unversioned
copies of the files remain. In the case here this was not, probably
as here no changes on them were pending, they were clean and
committed.
I suppose that the copies in newfolder would not have gone if
newfolder had been on the same or even higher level than the
source folder (/trunk/public/file1.txt => /trunk/parking/file1.txt),
provided that public was updated, not trunk - which cannot be
guaranteed ...
> > 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.
We need to temporarily remove files from a web project, yet want
them still to be around for possible internal edits so they are up-to-
date when they are brought back into the public part of the project.
We plan to move them to the "parking lot" one by one or in logical
groups likely to be resurrected in their old place together.
The recipe above simplified things a bit as in the real case the
move to the parking lot also includes removal of links to the moved
file in other places, all of which shall be resurrected some day, too.
Branching obviously would be no better a solution, besides this is
neither the private affair of one developer nor for an overseeable
period of time.
> > 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 :)
The grey hair SVN .24-1.0 grew me aside - would there be
Windows binaries available? I can't compile myself and would not
be able to do any testing before mid-January the earliest anyway
(we did not even update clients from 1.4.6 for not risking any
additional issues at this point of time; the server has 1.5.1 though,
with full dump/load trimmings, but that was just before scheduling
became tight).
> Honestly, this kind of testing is really important and helps
> Subversion a great deal. It's a great way to contribute.
I can understand that and would be glad to help as good as I can.
> > There's
> > documentation of the issues in the subversion repository:
I shall give all the papers some more reading, even if just for
curiosity. At the moment I am in much too tight a schedule, yet
had to confirm the behaviour.
TIA
Jan Hendrik
---------------------------------------
Freedom quote:
The unity of freedom has never relied on uniformity of opinion.
-- John F. Kennedy
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=995762
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2008-12-30 10:56:09 CET