On 3/27/07, Vincent Lefevre <email@example.com> wrote:
> On 2007-03-25 20:21:03 +0200, Aryeh Leib Taurog wrote:
> > I've been reading the discussion of versioning mtime and have added
> > myself to the cc list for issue 1256. This has just become an issue
> > for me, so I'm glad to see it is for others as well. I'm a newbie (I
> > switched from cvs to svn about 5 months ago).
> After the discussion about issue 2746, issue 1256 should be wontfix.
> Subversion can't do things incompatible with programs that backdate
> the mtime (regarding such programs as "broken and dangerous") and
> behaves like such programs (even optionally).
Backdating changing in itself is not a problem. It just that 1
specific value isn't working out that great when the file hasn't
changed in size. This almost never a problem, even if Vincent wants
you to believe it is. There are a number of scenarios where it may
lead to undetected changes in files. These scenarios are rare at best
Vincent is frustrated with the fact that we don't want to listen to
him - at least, that's what I suppose he's feeling - whereas we've
been rehashing all possibilities to improve the situation regarding
the value we assign to mtime+file size in the past weeks (again!).
This discussion was entirely due to his persisted requests to
reconsider the situation. (So, you see, we think we are listening to
him.) We've over and over come to the conclusion we can't do better
than we currently do within the bounds of reasonable performance.
All of that isn't very much on topic, but I wanted to tell you where
his comments might be coming from.
Issue 1256 definitely isn't related to 2746 in the way that Vincent
states. That's because it is about *recording* mtimes, not about
restoring them - a script should easily be able to restore them
though. So, thanks for your input and please stay tuned for a mail
about discussion of issue 1256.
BTW: Are you aware of the way OpenSource communities share changes?
They use 'svn diff', send each other the output and apply the
differences with a tool called 'patch'. Subversion puts the base
revision numbers in the diff, so you know exactly what base version
the diff was generated against (when applying the diff, this can be
extremely helpfull!). Maybe you and your client can explore this means
of sharing / exchanging changes?
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Mar 27 10:39:50 2007