Concerning Re: Is there really no way to keep
Steve Bakke wrote on 6 Mar 2007, 13:17, at least in part:
> On 3/6/07 10:53 AM, "Jan Hendrik" <jan.hendrik@myrealbox.com> wrote:
>
> <snip>
>
> > I don't follow the list as closely as I did between versions .27 &
> > 1.0 (it was just the dev list of course, users came in only later)
> > and therefore appologize if I am mistaken, but from some recent
> > postings I got the impression that the philosophy behind Subversion
> > has turned by 180 degrees since. Back then it was always that
> > Subversion would go to the moon to prevent any loss of user data,
> > these days to me it rather looks like the user has to go to the moon
> > himself to accomodate Subversion. (And it seems fitting that
> > TortoiseSVN has selection/confirmation dialogs for about
>
>
> >
> > Even more so as I just happened to come accross another issue of
> > user data loss, involving no fiddling with mtime or other stuff
> > except Subversion. I have not yet checked if it is documented or by
> > design:
> >
> > # Create a new repo and check out a working copy
> > $ svnadmin create repo
> > $ svn co file:///path/to/repo wc
> > Checked out revision 0.
> > $ cd wc
> >
> > # Create a file
> > $ echo hello > foo.txt
> > $ dir
> > 06.03.07 12:40 7 foo.txt
> > # Note: file is present and 7 bytes long
> >
> > # Add and commit it
> > $ svn add foo.txt
> > A foo.txt
> > $ svn ci -m ""
> > Adding foo.txt
> > Transmitting file data .
> > Committed revision 1.
> >
> > # now we delete foo.txt and create another foo.txt
> > # (move would do the dame)
> > $ svn rm foo.txt
> > D foo.txt
> > $ dir
> > # Note: there is no foo.txt anymore
> > $ echo goodbye > foo.txt
> > $ dir
> > 06.03.07 12:42 9 foo.txt
> > # Note: foo.txt is present and 9 bytes long.
> >
> > # now we revert our change to foo.txt
> > $ svn revert foo.txt
> > Reverted "foo.txt"
> > $ cat foo.txt
> > hello
> >
> > # The second foo.txt, created after deleting/moving the first one,
> > # is lost -- without any warning, conflict, whatsoever.
> >
>
> You never committed the file deletion in the first place, so this is
> not data loss. If you wanted the second file to be retained, then you
> need to commit the deletion first.
>
> At that point, if you created a new foo.txt, a revert command would
> have no effect, since it is not under revision control. This is just
> a case of mis-using the tool.
By its very nature revert can mean data loss, but reverting file
delete should not overwrite files, at least not without warning, or
Subversion should prevent creation of a new file in the first place
until commit of the deletion. Any decent OS handles this without
rebooting and issues a warning if one attempts to undo a
delete/rename/move that would overwrite something.
The user's task was to add (and occasionally replace) a series of
JPEGs in a new uniform format. Halfway through the user came
accross one image that was re-used at a rather distant place of the
web project where the new image size would not fit, however. To
keep in line with naming policy of basic image use he decided to
rename the original file and adjust the SRC path at the distant
location appropriately. A few images further on in his task he
recollected SVN would not allow him to add that new image
because of the pending rename of the original one. He also
remembered that SVN does not do clean renames, but copies &
deletes, so he decided to undo just the delete. SVN did without
warning. On other occasions one has to use a --force switch, e.g.
renaming a modified file (at least it used to be that way). Checking
the result of this operation the user found what happened and
called me in.
Examining the options for future handling we found:
1) commit after svn rename: the commit would have included part
of the user's not yet finished task, a bad thing and also against
SVN's own logic of atomic commits;
2) postponing the rename until the original task is complete &
committed: a bad thing as the image re-used in the other place
would be broken in one or more revisions;
3) checking out another WC, doing the rename&commit there, then
update the actual WC: taking a very long time&bandwidth for a
minor operation, good chance of unnecessary conflict;
4) checking out just the folder with the JPEGs and the folder/s
where the image was re-used: would require at least two commits
(for each folder, increasing with the number of re-use in different
locations), thus breaking up things again;
We decided that it would have been best to simply copy the
original image, against human logic in this case, but still within
SVN's logic breaking up rename/move into copy & delete anyway.
It was quite fortunate that it was not some copytext that was lost,
taking hour/s and inspiration to do again, the JPEG could be
recreated from the RAW source easily enough.
Mis-use is quite a harsh word for a rather normal operation which
just Subversion handles different from any OS. Obviously it did
what it was requested to do, but it did it as no decent OS and no
decent application should do: without requesting confirmation or a
special switch telling it the user is aware of the risk of overwriting
something. In other circumstances the user even might not be
aware anymore he had created a new file in the old place. At least
SVN raises a conflict in Harry's new foo.txt if Sally had modified
and committed her (old) foo.txt and Harry does an update before
committing the rename to foo-new.txt. But svn revert still would not
warn about the pending conflict and just revert to now Sally's
version, losing Harry's new stuff. Yet this might be called mis or
unproper use of Subversion as the user first should have looked
into what the conflict in the update was.
JH
---------------------------------------
Freedom quote:
We can't expect the American People
to jump from Capitalism to Communism,
but we can assist their elected leaders
in giving them small doses of Socialism,
until they awaken one day to find that they have Communism.
-- Nikita Khrushchev,
on the political trend launched by Roosevelt's 'New Deal'
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 9 12:51:33 2007