Concerning Re: Is there really no way to keep
Erik Huelsmann wrote on 5 Mar 2007, 14:49, at least in part:
> On 3/5/07, Les Mikesell <lesmikesell@gmail.com> wrote:
> > Erik Huelsmann wrote:
> >
> > >>
> > >> > We have the constant argument that the modification date time
> > >> > is unreliable, unfortunately this statement is driven by
> > >> > programs like subversion that throw this information away, thus
> > >> > making the modification date time unreliable.
> > >>
> > >> While at the same time relying on just this - and only on this -
> > >> for commit!
> > >
> > > Absolutely not!
> > >
> > > Subversion has a heuristic to determine whether it may need to
> > > commit a file or not. Loosing the mtime (ie damaging) is no
> > > problem for subversion: the timestamp will have changed and this
> > > means the file needs to be further inspected to see if a commit is
> > > required.
> > >
> > > See, that's why Subversions behaviour isn't problematic from a
> > > 'mtime is unreliable' pov: as soon as the mtime gets 'damaged',
> > > the file will be further inspected. This means slowing down the
> > > commit, but nothing more. 'Damaging' the mtime, as you can see, is
> > > not a problem for Subversion.
> >
> > Unless, of course, the 'damage' happens to be setting the mtime to
> > exactly match the pristine copy under .svn (or probably vice versa)
> > so that no further inspection happens at all even if the file is
> > changed. That sounds like a big problem to me.
>
> But chances are slim this actually happens: of all 2^31 seconds in a
> time_t, the damage would have to fall exactly on that second...
Chances are an evil thing to build upon. Overhere chances are
great we tread onto each other's feet for quite a lot webfiles.
Except for one single file chances are very low we conflict on Word
files. Chances are almost null for concurrent editing of the same
JPG file. And chances are actually null for conflicts with RAW
photo files - as the RAW editor is installed on exactly one machine.
> Just kidding.
>
> These posts bare no relation to the original subject in the thread
> anymore. I think the Original Poster has gotten a response and we can
> call this thread concluded.
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
everything but delete.) My case of deliberately setting back mtime
may be special, but AFAIU recode preserves mtime by default and
isn't just another foolish, outdated Windows editor/tool any
reasonable guy can and should neglect to take care of. I probably
should be aware from the start that deliberately working on mtime
might have unwanted side effects, an average user of a tool like
recode has no good reason to expect issues with Subversion.
Of course it is impossible to prepare for any circumstance, but on
one hand we constantly get told mtime is unreliable and useless
while on the other hand Subversion just takes chances on this very
mtime without taking into account any other parameter for making
vital decisions. That's quite strange.
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.
So far this other thing with user data lost without notice.
I was just ready to file the mtime-related issue on local changes
lost on svn update (see http://svn.haxx.se/users/archive-2007-
02/1071.shtml), only finding that registering with collab.net isn't
enough for filing issues, and I have to go through the hoop of
another application first. I wonder if it really is worth the while, not
least with a mail account that will die in three weeks anyway, for
this doesn't seem to be on the user's road to the moon.
I don't mean to become personal, just a little sarcastic.
JH
---------------------------------------
Freedom quote:
Je mehr Freiheit, desto weniger Gleichheit;
je mehr Gleichheit, desto weniger Freiheit.
-- Max Horkheimer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 6 17:31:44 2007