Concerning Re: Is there really no way to keep the file modif
Ryan Schmidt wrote on 6 Mar 2007, 20:07, at least in part:
> On Mar 6, 2007, at 12:17, Steve Bakke wrote:
> >> 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.
Subversion never told the user to do so. For the user the file was
gone, nothing kept him from creating a new one with the same
name. The user even might have no intention to bring the new one
under version control. IIRC Subversion tells the user it can't add
such a file before the delete was committed.
If a file is moved in filemanager, then a new one created, finally the
first one attempted to be moved back into its former location,
filemanager will ask/warn before overwriting the new one.
Subversion also stops updating/committing in case Steve and Slim
have both created foo.txt in the same location of their WCs, and
one of them has already committed this. But in this case it will not
delete/overwrite anything. At least it did not in the past.
> Steve, if you follow Jan,s script above, you will see that the file
> foo.txt that the user created with the contents "goodbye" was deleted
> by Subversion without notification. That is, by definition, data
> loss, and Subversion should not do that. (There are many places where
> texts claim that Subversion will not lose your data.) Jan, this
> sounds like a bug, and if it's not already submitted, I would
> recommend submitting it.
Yes, Ryan, I'll go to check if it's already filed, otherwise file it.
> Yes, unfortunately, to submit a bug, you must not only register at
> tigris, then also request observe rights for the subversion project.
> I hope you will do this and submit the bug, so that the problem is
> recorded in the database and it has a hope of getting fixed.
I did meanwhile, now waiting for grant of observer status. Can take
days till I get it though, MyRealBox, the email provider for this mail
account, is about unusable these days. Unfortunately I have yet to
find a suitable replacement. Gmail isn't available here anymore,
Yahoo has no native POP3, and neither one of these or others
allows use of the name part ("jan.hendrik"). So still searching for
something that provides a degree of anonymity without being a
phantasy of characters and numbers like a spammer ...
Socialism in general has a record of failure so blatant
that only an intellectual could ignore or evade it.
-- Thomas Sowell
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Mar 9 12:50:45 2007