You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Aryeh Leib Taurog <Ar...@AryehLeib.com> on 2007/03/25 18:21:03 UTC
retroactive mtime versioning
Hello all,
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).
So, although this is much related to the earlier thread
http://svn.haxx.se/users/archive-2007-03/0016.shtml
this seemed a sufficiently different topic to start a new thread.
As a consultant, I work mostly on a remote machine at my client's
site, but I keep my own local svn repository. The clients integrate
my work into their own code base using the files I put on their
machine. When I started this job, I checked their entire code-base
into my local repository. Only later did I discover that the
import/checkout process reset the mtime of all my files. The only
major issue for me was synching changes I make on my local machine
with those on the remote machine and vice-versa. I figured I would
just go ahead and reset all the mtimes on the remote machine as well...
Then I heard from the client. They *must* have the original mtimes
(for files I don't modify, obviously).
Short of starting a new repository and re-importing with Oliver Betz's
script, or compiling the branch of svn that maintains mtime, is there
any way to *reset* the mtime of the files already in the repository to
match the times my client wants? (i.e. the original times)
If I must start again, which of the two above methods is recommended?
I would think that using the perl script is easier than
recompiling. What is the status of the branch? Does it provide the
desired mtime functionality? When was the last merge from trunk?
There wasn't much mention of it in the thread I mentioned above.
Also, how easy would it be to implement Norbert Unterberg's suggestion
of building a dump file with the proper commit times?
Also, if I have to start again, how easy would it be to add back the
full version histories of 20-30 files I touched since I started the
project? Is it possible to dump only those? Does svndumpfilter
accept wildcards yet?
Thanks much,
Aryeh Leib
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: retroactive mtime versioning
Posted by Ryan Schmidt <su...@ryandesign.com>.
On May 29, 2007, at 16:51, Aryeh Leib Taurog wrote:
> Ryan Schmidt wrote:
>> On Mar 25, 2007, at 13:21, Aryeh Leib Taurog wrote:
>>> Then I heard from the client. They *must* have the original
>>> mtimes (for files I don't modify, obviously).
> >
>> If you want to store modification times of each file, I see two
>> options. One, you can commit each file as a separate revision,
>> then set the svn:date property of the just-committed revision to
>> match what the mtime of the file was. Repeat for all files.
>> Or two, you can attach a new property (e.g. x-mtime) to each time.
>> Set that property to the actual modification time of the file.
>> Perhaps invent a script which handles the commit, by attaching the
>> property and then calling svn ci. Invent another script to replace
>> svn checkout, which checks out, and then also sets the actual
>> mtimes of the files as per the contents of the new property.
>
> I've been playing with these two options for the last two months,
> but don't have what I consider to be a satisfactory solution.
> Either way I end up with something clumsy, slow, or both. I think
> the only viable way to do this would be to modify svn itself to
> maintain the mtime property. It's a pity it hasn't been done yet.
It has been done before: the text-time branch:
http://svn.collab.net/viewvc/svn/branches/meta-data-versioning/
Unfortunately that code hasn't been touched in two years.
> For anyone who's curious, I've put the gory details of my struggle,
> along with all my scripts, at http://www.aryehleib.com/svn/svn.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: retroactive mtime versioning
Posted by Aryeh Leib Taurog <Ar...@AryehLeib.com>.
Ryan Schmidt wrote:
> On Mar 25, 2007, at 13:21, Aryeh Leib Taurog wrote:
>
>> Then I heard from the client. They *must* have the original mtimes
>> (for files I don't modify, obviously).
>
> If you want to store modification times of each file, I see two options.
> One, you can commit each file as a separate revision, then set the
> svn:date property of the just-committed revision to match what the mtime
> of the file was. Repeat for all files.
>
> Or two, you can attach a new property (e.g. x-mtime) to each time. Set
> that property to the actual modification time of the file. Perhaps
> invent a script which handles the commit, by attaching the property and
> then calling svn ci. Invent another script to replace svn checkout,
> which checks out, and then also sets the actual mtimes of the files as
> per the contents of the new property.
I've been playing with these two options for the last two months, but
don't have what I consider to be a satisfactory solution. Either way
I end up with something clumsy, slow, or both. I think the only
viable way to do this would be to modify svn itself to maintain the
mtime property. It's a pity it hasn't been done yet.
For anyone who's curious, I've put the gory details of my struggle,
along with all my scripts, at http://www.aryehleib.com/svn/svn.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: retroactive mtime versioning
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 25, 2007, at 13:21, Aryeh Leib Taurog wrote:
> Then I heard from the client. They *must* have the original mtimes
> (for files I don't modify, obviously).
>
> Short of starting a new repository and re-importing with Oliver
> Betz's script, or compiling the branch of svn that maintains
> mtime, is there any way to *reset* the mtime of the files already
> in the repository to match the times my client wants? (i.e. the
> original times)
You cannot reset mtimes because Subversion never stores the mtimes.
You can change any revision's commit time (svn propset --revprop -r
123 svn:date <NEWDATE>) but that time then applies to all files
included in that revision.
If you want to store modification times of each file, I see two
options. One, you can commit each file as a separate revision, then
set the svn:date property of the just-committed revision to match
what the mtime of the file was. Repeat for all files.
Or two, you can attach a new property (e.g. x-mtime) to each time.
Set that property to the actual modification time of the file.
Perhaps invent a script which handles the commit, by attaching the
property and then calling svn ci. Invent another script to replace
svn checkout, which checks out, and then also sets the actual mtimes
of the files as per the contents of the new property.
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: retroactive mtime versioning
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2007-03-27 10:39:22 +0200, Erik Huelsmann wrote:
> Backdating changing in itself is not a problem.
This is not what Ben Collins-Sussman said:
"We've had a policy (since the beginning) of not acknowledging tools
that change file contents without changing the timestamp. The 2 or 3
times we've discovered such tools, we've always shouted them down as
dangerous and broken, and they've been fixed. I don't see the latest
complaint as anything new."
(and when replying to this message, you didn't make any comment on
this point -- I assume you agree with Ben). So, if Subversion does
the same things, it is broken and dangerous. That's all.
> 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 though.
They are rare in your opinion. I agree that most users won't be
affected. But you cannot know what some particular user will do.
And I recall that the user may lose some of his data. Even if this
is rare, I don't think any user will accept losing his data.
Subversion should take care of that, in one way or another.
> Vincent is frustrated with the fact that we don't want to listen to
You're completely wrong. I suggested the wontfix here only because
Subversion developers say that such a behaviour is "dangerous and
broken".
> 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!).
Note that I've never asked to consider the file size. I'm not even sure
that this is a good solution because it leads to inconsistent behavior.
Say, the user uses "recode" on a set of files, then does a "svn ci" and
sees that files are committed. He may then think that everything is OK,
but in fact, if some file size has not changed (I showed that this could
happen in real files), then this file has not been committed, and the
user may miss that.
Of course, in this case, the loss is probably not critical, but when
data integrity is concerned, what a developer should do is not "let's
implement this, and if we don't know any example that will lead to a
loss of data, that's fine", but "if I implement this, can I show that
it is not possible to lose data?".
> This discussion was entirely due to his persisted requests to
> reconsider the situation.
Note that in the first discussion, it was said that ctime was replaced
by mtime only because of Windows. That's why I asked it to be
reconsidered a few days ago.
> (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.
Your conclusion is wrong. First, making the heuristic choice optional
is a better solution: Windows and USB card users will still choose
the current behavior, while the other users could choose a much more
reliable solution (e.g. the mtime+inode solution, which should work
in more cases than ctime) without sacrificing performance. So, for
some users, the behavior won't change, and for other users, it will
be more reliable with the same performance. Globally, this would be
better.
Second, rsync, whose heuristic is also based on mtime, has an option
to ignore mtime (even if the behavior is slower, this is useful when
the user knows that there can be problems and/or before a change that
couldn't be reverted): --ignore-times. Similarly, the "make" command
has option -W (and "make clean" is a better solution if everything
needs to b rebuilt). I don't know any other software that is based
on mtime (AFAIK, backup software are based on ctime or read the
files, precisely because mtime is not reliable).
Third, Subversion's behavior is not documented (issue 2719).
> 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
No, issue 1256 is about recording mtimes *and* restoring them.
Summary: Ability to preserve last modification time (mtime) of files
under version control
Sometimes it is useful to preserve creation/modification time of a
files under version control. File importing/adding/committing should
save these times together with all other file properties and checkout
of this file should restore these times instead of putting current
^^^^^^^
time. [...]
> - a script should easily be able to restore them though. [...]
If this is a script, that would definitely be the user's problem.
Thus that would be fine as far as Subversion is concerned.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: retroactive mtime versioning
Posted by Erik Huelsmann <eh...@gmail.com>.
On 3/27/07, Vincent Lefevre <vi...@vinc17.org> 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
though.
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?
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: retroactive mtime versioning
Posted by Vincent Lefevre <vi...@vinc17.org>.
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).
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org