You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Frans Knibbe <fr...@geodan.nl> on 2007/02/26 13:30:28 UTC
Is there really no way to keep the file modification time intact?
Hello,
I have seen the subject pass by a few times in this list: subversion
changes the file (modification) time to the commit time when you put a
file in the repository. It is not possible to override this behaviour. I
think is a fundamental problem with subversion. Whether I copy the file
to another location, or compress it in an archive, or put it in a
subversion repository, the time the file was last modified should not
change. In other words: I think subversion should not tamper with files
it stores. I want my files to come back exactly like they were when I
put them in the repository. And that includes the time of the last
modification.
Now I have found that this problem is already an offcial issue. Its
number is 1256
(http://subversion.tigris.org/issues/show_bug.cgi?id=1256). But the
issue has remained unresolved for a long time. I see it has now been
postponed to version 1.5. I do hope this bug really gets solved soon.
But I really can not wait for version 1.5. My organization is moving
from another source control system to SVN and I have to write an
importer. As it is now, it seems that all the files in the repository
will wind up with the file time set to the moment they are handled by
the importer. That means that a lot of useful and maybe vital
information will get lost.
Does anyone know of a way to put files in a subversion repository with
the file time intact?
Regards,
Frans
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Norbert Unterberg <nu...@gmail.com>.
2007/2/26, Frans Knibbe <fr...@geodan.nl>:
> But I really can not wait for version 1.5. My organization is moving
> from another source control system to SVN and I have to write an
> importer. As it is now, it seems that all the files in the repository
> will wind up with the file time set to the moment they are handled by
> the importer. That means that a lot of useful and maybe vital
> information will get lost.
I am a little late on this thread.
There is another way of converting to Subversion: Write an importer
that creates a dump file, and then import this dump file int a new SVN
repos. Then you have full control over all propertiers and commit
dates, regardless of the current client's or server's time.
As far as I know, the cvs to svn script works this way.
And it is much faster to test and debug, I guess running your
converter doing real checkins for every revision might take some time.
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Oliver Betz <li...@gmx.net>.
Frans Knibbe wrote:
[...]
> I think I could also temporarily set the system time to the file
> modification time before I commit each file, just during the migration
shudder. You can set this property explicitly.
Didn't you look at the script I mentioned?
svn.haxx.se/users/archive-2006-10/1345.shtml
Oliver
--
Oliver Betz, Muenchen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Oliver Betz <li...@gmx.net>.
Frans Knibbe wrote:
[...]
> If I read your script correctly, you commit a file and then you use svn
> propset to alter the svn:date property. Well, that is a nicer way of
> doing it, indeed. I did not realize this was possible. But now I have
> also read the warning in the SVN book:
>
> "Since the timestamp of a revision is stored as an unversioned,
> modifiable property of the revision (see the section called
> "Properties", revision timestamps can be changed to represent complete
> falsifications of true chronology, or even removed altogether. This will
> wreak havoc on the internal date-to-revision conversion that Subversion
> performs."
I don't know about "internal date-to-revision conversion that
Subversion performs".
Since my script sorts the files before committing, I don't think that
there can be any problem.
> Have you ever noticed any havoc resulting from you migration? If I
No. But I used it only for initial import of a small number of soucre
file trees.
> understand correctly, the effect to avoid is the -r{DATE}switch
> returning a wrong revision number. So if I first sort all the objects I
> want to commit by date, there won't be a problem. I hope...
That's what my script does and why I wrote it.
Oliver
--
Oliver Betz, Muenchen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Frans Knibbe <fr...@geodan.nl>.
Oliver Betz wrote:
> Frans Knibbe wrote:
>
> [...]
>
>
>> Thank you for your suggestions. I have done some testing and I think I
>> will choose the option to set the system time to the file modification
>> time before each commit.
>>
>
> why don't you want to use "svn propset" as I suggested?
>
That's strange. I did not receive earlier messages from you in this
thread. But then I went to look in the mailing list archive at
http://subversion.tigris.org and there I saw your other message. Maybe
it was delayed or somehow did not get through out spam filter? I will
ask my system administrator.
So, thanks for the link! It seems you were faced with with the same
problem I have now.
If I read your script correctly, you commit a file and then you use svn
propset to alter the svn:date property. Well, that is a nicer way of
doing it, indeed. I did not realize this was possible. But now I have
also read the warning in the SVN book:
"Since the timestamp of a revision is stored as an unversioned,
modifiable property of the revision (see the section called
“Properties”, revision timestamps can be changed to represent complete
falsifications of true chronology, or even removed altogether. This will
wreak havoc on the internal date-to-revision conversion that Subversion
performs."
Have you ever noticed any havoc resulting from you migration? If I
understand correctly, the effect to avoid is the -r{DATE}switch
returning a wrong revision number. So if I first sort all the objects I
want to commit by date, there won't be a problem. I hope...
>
>> It is a simple solution and I think it is
>>
>
> IMNSHO it's a horrible way to do it.
>
> Oliver
>
--
-------------------------------------
Frans Knibbe
Geodan S&R
President Kennedylaan 1
1079 MB Amsterdam (NL)
-------------------------------------
Tel: +31 (0)20 - 5711 347
Fax: +31 (0)20 - 5711 333
-------------------------------------
E-mail: frans.knibbe@geodan.nl
Website: www.geodan.nl
KvK-nummer: 33 247475
Disclaimer: www.geodan.nl/disclaimer
-------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Oliver Betz <li...@gmx.net>.
Frans Knibbe wrote:
[...]
> Thank you for your suggestions. I have done some testing and I think I
> will choose the option to set the system time to the file modification
> time before each commit.
why don't you want to use "svn propset" as I suggested?
> It is a simple solution and I think it is
IMNSHO it's a horrible way to do it.
Oliver
--
Oliver Betz, Muenchen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Frans Knibbe <fr...@geodan.nl>.
Les Mikesell wrote:
> Frans Knibbe wrote:
>>
>>> Sounds like you should just be writing a wrapper script to go around
>>> "svn checkout", which itself calls svn checkout, then mucks with the
>>> modification dates of the checked-out files in whatever way you like.
>>>
>>>
>>> [1] I did write a script to implement a post-checkout hook, but it
>>> is a server-side script, of course; it does not do anything on the
>>> client:
>>> http://www.ryandesign.com/svnhookdispatcher
>
>> Thank you for your suggestions. I have done some testing and I think
>> I will choose the option to set the system time to the file
>> modification time before each commit. It is a simple solution and I
>> think it is sufficient for our purposes. All migrated files will have
>> recorded commit times equalling file modification times. All future
>> changes will just have a commit time, but this time will not differ
>> much from the file modification time if users don't wait too long
>> before comitting.
>
> That sounds absolutely horrible in any scenario that could possibly
> have multiple users or concurrent commits happening at once.
Yes, it sounded horrible to me too at first. But I am running the
migration to local Subversion repositories, one file revision at a time.
After the migration is finished, other users will be given access to the
repository. I have tested the concept manually and there were no
problems. I fear that if a try another solution I will get myself in
worse problems, especially because I am new to Subversion. The nice
thing is that this way, the dates as returned by the svn log command are
meaningful, i.e. reflecting true commit dates.
--
-------------------------------------
Frans Knibbe
Geodan S&R
President Kennedylaan 1
1079 MB Amsterdam (NL)
-------------------------------------
Tel: +31 (0)20 - 5711 347
Fax: +31 (0)20 - 5711 333
-------------------------------------
E-mail: frans.knibbe@geodan.nl
Website: www.geodan.nl
KvK-nummer: 33 247475
Disclaimer: www.geodan.nl/disclaimer
-------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Les Mikesell <le...@gmail.com>.
Frans Knibbe wrote:
>
>> Sounds like you should just be writing a wrapper script to go around
>> "svn checkout", which itself calls svn checkout, then mucks with the
>> modification dates of the checked-out files in whatever way you like.
>>
>>
>> [1] I did write a script to implement a post-checkout hook, but it is
>> a server-side script, of course; it does not do anything on the client:
>> http://www.ryandesign.com/svnhookdispatcher
> Thank you for your suggestions. I have done some testing and I think I
> will choose the option to set the system time to the file modification
> time before each commit. It is a simple solution and I think it is
> sufficient for our purposes. All migrated files will have recorded
> commit times equalling file modification times. All future changes will
> just have a commit time, but this time will not differ much from the
> file modification time if users don't wait too long before comitting.
That sounds absolutely horrible in any scenario that could possibly have
multiple users or concurrent commits happening at once.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Frans Knibbe <fr...@geodan.nl>.
Ryan Schmidt wrote:
>
> On Feb 27, 2007, at 08:37, Frans Knibbe wrote:
>
>>> Only if you put the file time in a custom property which you restore
>>> after checking out.
>>
>> Yes, I thought about that too. That way, the file modification time
>> would not be really lost but just stored in a different way. And if
>> something like a post-checkout hook existed I could even reset the
>> file time of the working copy. But such a hook does not exist....
>
> Not only is there no post-checkout hook [1] but hooks run on the
> server, and it sounds like you are asking for hook that runs on the
> client. No Subversion hooks currently run on the client, so this would
> be much work to implement. And I believe that because of potential
> platform differences and differences in installed scripting languages
> on clients, client-side hooks are a very prickly proposition.
>
> Sounds like you should just be writing a wrapper script to go around
> "svn checkout", which itself calls svn checkout, then mucks with the
> modification dates of the checked-out files in whatever way you like.
>
>
> [1] I did write a script to implement a post-checkout hook, but it is
> a server-side script, of course; it does not do anything on the client:
> http://www.ryandesign.com/svnhookdispatcher
Thank you for your suggestions. I have done some testing and I think I
will choose the option to set the system time to the file modification
time before each commit. It is a simple solution and I think it is
sufficient for our purposes. All migrated files will have recorded
commit times equalling file modification times. All future changes will
just have a commit time, but this time will not differ much from the
file modification time if users don't wait too long before comitting.
Cheers,
Frans
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Feb 27, 2007, at 08:37, Frans Knibbe wrote:
>> Only if you put the file time in a custom property which you restore
>> after checking out.
>
> Yes, I thought about that too. That way, the file modification time
> would not be really lost but just stored in a different way. And if
> something like a post-checkout hook existed I could even reset the
> file time of the working copy. But such a hook does not exist....
Not only is there no post-checkout hook [1] but hooks run on the
server, and it sounds like you are asking for hook that runs on the
client. No Subversion hooks currently run on the client, so this
would be much work to implement. And I believe that because of
potential platform differences and differences in installed scripting
languages on clients, client-side hooks are a very prickly proposition.
Sounds like you should just be writing a wrapper script to go around
"svn checkout", which itself calls svn checkout, then mucks with the
modification dates of the checked-out files in whatever way you like.
[1] I did write a script to implement a post-checkout hook, but it is
a server-side script, of course; it does not do anything on the client:
http://www.ryandesign.com/svnhookdispatcher
--
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: Is there really no way to keep the file modification time intact?
Posted by Les Mikesell <le...@gmail.com>.
Frans Knibbe wrote:
>> I want my files to come back exactly like they were when I
>>
>> Um, no. That's not 'the file', that's 'data about the file' -
>> metadata. Subversion only versions directory trees, not the metadata
>> which may be associated with directory trees.
> I find it hard to draw a line between the file data and its metadata.
> Is the file name a metadatum? Are the file permissions metadata? Is it
> possible to make these distinctions regardless of the type of file system?
Subversion isn't the first program that knows how to move files around.
This problem was solved long ago in tar, and similarly in rsync (and
both have odd extensions for mac resource forks...). There's a certain
amount of stuff to store and a certain amount that gets lost crossing
platforms. File modified timestamp is used everywhere.
> Yes, I thought about that too. That way, the file modification time
> would not be really lost but just stored in a different way.
svn info will give you the commit time of the file - and I think you are
allowed to modify this.
> I think I could also temporarily set the system time to the file
> modification time before I commit each file, just during the migration
> process. That way, commit time would always be equal to file
> modification time. But I really hope I can avoid having to do something
> a dirty as this.
Setting it to the time that svn info shows as the last changed date
might make more sense. That will at least serialize things around
commits which is probably what you want even if someone commits a file
with an old timestamp.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Frans Knibbe <fr...@geodan.nl>.
Erik Huelsmann wrote:
> On 2/26/07, Frans Knibbe <fr...@geodan.nl> wrote:
>> Hello,
>>
>> I have seen the subject pass by a few times in this list: subversion
>> changes the file (modification) time to the commit time when you put a
>> file in the repository.
>
> Not exactly. It doesn't record the modification time.
Ah, thank you. I did not know that. If no file modification times are
stored I can see why resolving this issue might be complicated.
>> put them in the repository. And that includes the time of the last
>> modification.
> I want my files to come back exactly like they were when I
>
> Um, no. That's not 'the file', that's 'data about the file' -
> metadata. Subversion only versions directory trees, not the metadata
> which may be associated with directory trees.
I find it hard to draw a line between the file data and its metadata.
Is the file name a metadatum? Are the file permissions metadata? Is it
possible to make these distinctions regardless of the type of file system?
>
>
> Do you only need this once? (on import) Or do you need it always? (on
> every commit)
>
> Well, if this behaviour is so important to you, and you need the
> second option (always), then is Subversion really the tool for your
> organization?
I think we need it always. But it would be nice to have at least during
the migration. Then at least the file times would still be in the same
order, and no great gaps in time would exist, assuming there will be not
too much time between file modification and commits.
Apart from this issue, Subversion does seem the right tool for our
organization.
>
>> As it is now, it seems that all the files in the repository
>> will wind up with the file time set to the moment they are handled by
>> the importer. That means that a lot of useful and maybe vital
>> information will get lost.
>>
>> Does anyone know of a way to put files in a subversion repository with
>> the file time intact?
>
> Only if you put the file time in a custom property which you restore
> after checking out.
Yes, I thought about that too. That way, the file modification time
would not be really lost but just stored in a different way. And if
something like a post-checkout hook existed I could even reset the file
time of the working copy. But such a hook does not exist....
I think I could also temporarily set the system time to the file
modification time before I commit each file, just during the migration
process. That way, commit time would always be equal to file
modification time. But I really hope I can avoid having to do something
a dirty as this.
>
> bye,
>
> Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Erik Huelsmann <eh...@gmail.com>.
On 2/26/07, Frans Knibbe <fr...@geodan.nl> wrote:
> Hello,
>
> I have seen the subject pass by a few times in this list: subversion
> changes the file (modification) time to the commit time when you put a
> file in the repository.
Not exactly. It doesn't record the modification time. If you want, you
can have one of 2 behaviours on checkout:
1) use the time of checking out (the default) [ie when the file is
created in the target filesystem]
2) use the time of the commit (optional in the client side configuration file)
> It is not possible to override this behaviour. I
> think is a fundamental problem with subversion.
Why? The file didn't exist in the target filesystem before you checked it out...
> Whether I copy the file
> to another location, or compress it in an archive, or put it in a
> subversion repository, the time the file was last modified should not
> change. In other words: I think subversion should not tamper with files
> it stores.
It doesn't. It just doesn't record the file's metadata.
> I want my files to come back exactly like they were when I
> put them in the repository. And that includes the time of the last
> modification.
Um, no. That's not 'the file', that's 'data about the file' -
metadata. Subversion only versions directory trees, not the metadata
which may be associated with directory trees.
> Now I have found that this problem is already an offcial issue. Its
> number is 1256
> (http://subversion.tigris.org/issues/show_bug.cgi?id=1256). But the
> issue has remained unresolved for a long time. I see it has now been
> postponed to version 1.5. I do hope this bug really gets solved soon.
>
> But I really can not wait for version 1.5. My organization is moving
> from another source control system to SVN and I have to write an
> importer.
Do you only need this once? (on import) Or do you need it always? (on
every commit)
Well, if this behaviour is so important to you, and you need the
second option (always), then is Subversion really the tool for your
organization?
> As it is now, it seems that all the files in the repository
> will wind up with the file time set to the moment they are handled by
> the importer. That means that a lot of useful and maybe vital
> information will get lost.
>
> Does anyone know of a way to put files in a subversion repository with
> the file time intact?
Only if you put the file time in a custom property which you restore
after checking out.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Erik Huelsmann <eh...@gmail.com>.
On 2/26/07, Frans Knibbe <fr...@geodan.nl> wrote:
> Hello,
>
> I have seen the subject pass by a few times in this list: subversion
> changes the file (modification) time to the commit time when you put a
> file in the repository.
Not exactly. It doesn't record the modification time. If you want, you
can have one of 2 behaviours on checkout:
1) use the time of checking out (the default) [ie when the file is
created in the target filesystem]
2) use the time of the commit (optional in the client side configuration file)
> It is not possible to override this behaviour. I
> think is a fundamental problem with subversion.
Why? The file didn't exist in the target filesystem before you checked it out...
> Whether I copy the file
> to another location, or compress it in an archive, or put it in a
> subversion repository, the time the file was last modified should not
> change. In other words: I think subversion should not tamper with files
> it stores.
It doesn't. It just doesn't record the file's metadata.
> I want my files to come back exactly like they were when I
> put them in the repository. And that includes the time of the last
> modification.
Um, no. That's not 'the file', that's 'data about the file' -
metadata. Subversion only versions directory trees, not the metadata
which may be associated with directory trees.
> Now I have found that this problem is already an offcial issue. Its
> number is 1256
> (http://subversion.tigris.org/issues/show_bug.cgi?id=1256). But the
> issue has remained unresolved for a long time. I see it has now been
> postponed to version 1.5. I do hope this bug really gets solved soon.
>
> But I really can not wait for version 1.5. My organization is moving
> from another source control system to SVN and I have to write an
> importer.
Do you only need this once? (on import) Or do you need it always? (on
every commit)
Well, if this behaviour is so important to you, and you need the
second option (always), then is Subversion really the tool for your
organization?
> As it is now, it seems that all the files in the repository
> will wind up with the file time set to the moment they are handled by
> the importer. That means that a lot of useful and maybe vital
> information will get lost.
>
> Does anyone know of a way to put files in a subversion repository with
> the file time intact?
Only if you put the file time in a custom property which you restore
after checking out.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 6, 2007, at 18:03, John Gwinner wrote:
> So to work through a scenario:
>
> Developer Fred and Bob start work on a project. They both save
> files on
> 12/24 and go celebrate Christmas. Bob gets a bug reported and
> fixes it
> directly in Production.
>
> Bob checks in all his files on 1/2 2007. He leaves the project.
>
> Fred is told by his Project Manager to make sure everything is checked
> in on 3/6 2007. He checks in all of his files from a different
> instance
> (Development), effective modification date of 12/24. His changes
> overwrite Bob's newer files.
>
> So we reverted, right?
If all these changes are being made in Subversion (all in the trunk,
or in different branches with changes merged between them), then
Fred's changes will not overwrite Bob's. Rather, Fred will get a
message that his files are out of date, and he must update his
working copy before he can commit. He updates, and receives Bob's
changes. Then he can commit his own, first resolving any conflicts,
if necessary.
--
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: Is there really no way to keep the file modification time intact?
Posted by John Gwinner <jg...@dazsi.com>.
(Thanks Ryan for the clarification on times).
> > Erik meant: add your email address to the cc list of the bug (not of
> > this email discussion).
>
> Yup. You can find the bug at
> http://subversion.tigris.org/issues/show_bug.cgi?id=1256
Right, I'd done that when I posted originally.
> When I'm looking
> for the amount of interest in an issue, I do look for signs of
> interest.
Well, I may be putting myself in harms way, o.O but I'd venture to say
that anyone thinking of migrating from SourceSafe will expect the check
in time to be file modification time.
They may or may not post on this list.
For PL/SQL packages, i.e. Oracle's JDeveloper, I'm not sure the concept
applies, although there is certainly a modification time in the package.
We would have the same issue here, developers won't check in anything
until the PM tells them to, then we get it all in a dump, possibly
overwriting older checkins.
So to work through a scenario:
Developer Fred and Bob start work on a project. They both save files on
12/24 and go celebrate Christmas. Bob gets a bug reported and fixes it
directly in Production.
Bob checks in all his files on 1/2 2007. He leaves the project.
Fred is told by his Project Manager to make sure everything is checked
in on 3/6 2007. He checks in all of his files from a different instance
(Development), effective modification date of 12/24. His changes
overwrite Bob's newer files.
So we reverted, right?
== John ==
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Erik Huelsmann <eh...@gmail.com>.
> > I am not familiar with this tactic for messages in a mailing-list.
> > I'm
> > don't understand how it could work reliably in practice, but I've
> > added
> > my address to the 'Cc:' of this here reply! :-)
>
> Erik meant: add your email address to the cc list of the bug (not of
> this email discussion).
Yup. You can find the bug at
http://subversion.tigris.org/issues/show_bug.cgi?id=1256
> The bug tracker has a feature where you can vote on issues you find
> important, but the developers have often said they don't pay
> attention to that. So they probably won't pay attention to the length
> of the cc list either. But it would be interesting to see, from the
> cc list, how many people really are interested in the feature.
Right. We don't pay attention to the length of the cc list (in
general), but it does give me an opportunity to reach those who have
expressed interest more specifically than sending an untargetted
e-mail to this list.
Anybody is free to cast votes as they like ofcourse. When I'm looking
for the amount of interest in an issue, I do look for signs of
interest. This includes votes, cc-list length and number of different
people commenting on the issue. But that only works when I'm
interested in solving the issue, not for issue selection (ie, it's not
like I'm going to select the issue with the most votes to work on).
HTH,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 5, 2007, at 23:56, Garance A Drosihn wrote:
> The time that subversion stores for the *revision* will be 3/2/2007.
> It is my understanding that subversion relies on the fact that the
> 'svn:date' property is never decreasing as revision-numbers increase.
> (disclaimer: Note that I may be wrong about that...)
True...ish. There is one feature that will break if your revision
dates are not always increasing: the feature where you can specify a
revision number by date. For example, "svn log -r {2007-03-05}" will
not work reliably if your dates are not in order. If you do not use
that feature, there is no problem.
> Certainly subversion expects the 'svn:date' property will have the
> exact
> same value for all files which are checked-in in a single 'svn:commit'
> command. I'm pretty sure you cannot avoid that fact. This is why it
> is so significant that the 'svn:date' is a property of the *revision*,
> and not a property of each file which was changed in that revision.
Well, more correctly: files and directories do not have an svn:date
property. Revisions do. (Put another way: svn:date is an unversioned
property of the revision, not a versioned property of a file or
directory.)
>> >Erik Huelsmann wrote:
>> >- everybody who is interested can add his/her username to the CC
>> list
>>
>> I added mine
>
> I am not familiar with this tactic for messages in a mailing-list.
> I'm
> don't understand how it could work reliably in practice, but I've
> added
> my address to the 'Cc:' of this here reply! :-)
Erik meant: add your email address to the cc list of the bug (not of
this email discussion).
The bug tracker has a feature where you can vote on issues you find
important, but the developers have often said they don't pay
attention to that. So they probably won't pay attention to the length
of the cc list either. But it would be interesting to see, from the
cc list, how many people really are interested in the feature.
--
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: Re: Is there really no way to keep the file modification
time intact?
Posted by Garance A Drosihn <dr...@rpi.edu>.
At 6:02 PM -0600 3/2/07, John Gwinner wrote:
>I haven't posted much but this sounds like a potentially
>critical issue to us.
>
>If I understand correctly, if I take a file that was
>modified, say in 2003:
>
>1/01/2003 15:54 16 test.me.txt
>or
>-rw-rw-rw- 1 user group 16 Jan 1 2003 test.me.txt
>
>Then I check it in today, the 'time' in Subversion will
>be 3/2/2007?
The time that subversion stores for the *revision* will be 3/2/2007.
It is my understanding that subversion relies on the fact that the
'svn:date' property is never decreasing as revision-numbers increase.
(disclaimer: Note that I may be wrong about that...)
Certainly subversion expects the 'svn:date' property will have the exact
same value for all files which are checked-in in a single 'svn:commit'
command. I'm pretty sure you cannot avoid that fact. This is why it
is so significant that the 'svn:date' is a property of the *revision*,
and not a property of each file which was changed in that revision.
>To me that's wrong.
>
>I agree it should be an option.
>
>There should also be an option to have the file check out with today's
>date, the modification date, or the check in date, in my opinion. I
>find all 3 useful in different scenarios.
Another possible solution is to add some new property, and let svn
continue to use the 'svn:date' property in whatever way it wants to.
Perhaps svn itself would keep track of this new property. If not,
then you've got to make sure to add the appropriate hooks to make
sure this property is updated at commit, and handled appropriately
at checkout/update time. It's a little work, but it certainly should
be doable.
One of the really nice things about subversion is that you can add
whatever properties you want to add, to track whatever meta-data you
want to track.
> >Erik Huelsmann wrote:
> >- everybody who is interested can add his/her username to the CC list
>
>I added mine
I am not familiar with this tactic for messages in a mailing-list. I'm
don't understand how it could work reliably in practice, but I've added
my address to the 'Cc:' of this here reply! :-)
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 3, 2007, at 00:57, Erik Huelsmann wrote:
> On 3/3/07, Ryan Schmidt wrote:
>
>> On Mar 2, 2007, at 18:02, John Gwinner wrote:
>>
>> > If I understand correctly, if I take a file that was modified,
>> say in
>> > 2003:
>> >
>> > 1/01/2003 15:54 16 test.me.txt
>> > or
>> > -rw-rw-rw- 1 user group 16 Jan 1 2003 test.me.txt
>> >
>> > Then I check it in today, the 'time' in Subversion will be
>> 3/2/2007?
>>
>> Yes, that is what will happen.
>
> No, Subversion doesn't record that.
Ok, to be more accurate:
If you commit something on 3/2/2007 at 12:34, the date/time
Subversion records for the revision will be 3/2/2007 at 12:34.
When you check it out again, the modification date/time of the files
you committed will either be the current date/time at time of
checkout (with use-commit-times=no, the default), or 3/2/2007 at
12:34 (with use-commit-times=yes).
--
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: Is there really no way to keep the file modification time intact?
Posted by Erik Huelsmann <eh...@gmail.com>.
On 3/3/07, Ryan Schmidt <su...@ryandesign.com> wrote:
> On Mar 2, 2007, at 18:02, John Gwinner wrote:
>
> > If I understand correctly, if I take a file that was modified, say in
> > 2003:
> >
> > 1/01/2003 15:54 16 test.me.txt
> > or
> > -rw-rw-rw- 1 user group 16 Jan 1 2003 test.me.txt
> >
> > Then I check it in today, the 'time' in Subversion will be 3/2/2007?
>
> Yes, that is what will happen.
No, Subversion doesn't record that.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time
intact?
Posted by Eric <sp...@scoot.netis.com>.
At 10:34 PM 3/2/2007, Ryan Schmidt wrote:
<RS>>>>>Subversion simply does not store a modification date/time per
file/directory. It only stores the time that you commit a revision.<<<<<
Good morning, Ryan.
We all (well, at least those of us who have been following this thread)
know this and understand it.
What we are saying is that the inability of Subversion to store
modification date/times is A Growing Problem for A Large And Growing Number
Of Subversion Users.
In our case, it's a major aggravation that we have resigned ourselves to
for the foreseeable future, except that it's yet another arrow in the
quiver of that one user I have discussed in the past, who considers
Subversion a toy that's not suitable for serious developers.
I consider that, and the inability to check out and check in individual
files within a directory, as being the ONLY two near-show-stoppers ...
EVERY other real or perceived shortcoming of Subversion is of medium
concern at worst, and mostly they're all minor and not anything we're
concerned about ... in fact if you asked me to list them I'd be
hard-pressed to do that (I really am easy to please). :-)
If I had to pick one of those two to be fixed, I'd pick the preservation of
the file modification date/times, and live forever with the inability to
check out individual files.
I realize that Subversion is free and no one appreciates the hard work of
the Subversion developers more than I do, but if you all could see your way
clear to fix that one thing, you would have my undying gratitude ... well,
actually, you already have that... :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 2, 2007, at 18:02, John Gwinner wrote:
> If I understand correctly, if I take a file that was modified, say in
> 2003:
>
> 1/01/2003 15:54 16 test.me.txt
> or
> -rw-rw-rw- 1 user group 16 Jan 1 2003 test.me.txt
>
> Then I check it in today, the 'time' in Subversion will be 3/2/2007?
Yes, that is what will happen.
> To me that's wrong.
Subversion simply does not store a modification date/time per file/
directory. It only stores the time that you commit a revision.
Whether that's "wrong" or not is debatable. For some applications,
obviously, it hasn't been a major problem, or else it would have been
changed by now.
> I agree it should be an option.
I would like the option to store the modification date/time as well.
> There should also be an option to have the file check out with today's
> date, the modification date, or the check in date, in my opinion. I
> find all 3 useful in different scenarios.
The default is currently to check out with today's date. You can set
use-commit-times=yes to get the check in date. You cannot currently
get the original modification date/time because Subversion does not
store that information.
--
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: Re: Is there really no way to keep the file modification time intact?
Posted by John Gwinner <jg...@dazsi.com>.
I haven't posted much but this sounds like a potentially critical issue
to us.
If I understand correctly, if I take a file that was modified, say in
2003:
1/01/2003 15:54 16 test.me.txt
or
-rw-rw-rw- 1 user group 16 Jan 1 2003 test.me.txt
Then I check it in today, the 'time' in Subversion will be 3/2/2007?
To me that's wrong.
I agree it should be an option.
There should also be an option to have the file check out with today's
date, the modification date, or the check in date, in my opinion. I
find all 3 useful in different scenarios.
>Erik Huelsmann wrote:
>- everybody who is interested can add his/her username to the CC list
I added mine
>I think my migration problem may be overlooked as a user requirement
for this issue.
Migration is definitely one thing, but not all - we frequently have
projects that aren't in source control, someone goes and prods
developers, and then they commit stuff, usually a large bunch of older
files.
== John ==
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Frans Knibbe <fr...@geodan.nl>.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Erik Huelsmann wrote:<br>
<blockquote
cite="midaea328ab0702280758t22186124na795dcdd7a268eca@mail.gmail.com"
type="cite"><br>
<blockquote type="cite">I think this would probably the best way to
handle the file modification
<br>
time. Define a new reserved property, something like
<br>
<a class="moz-txt-link-freetext" href="svn:modification-time">svn:modification-time</a> and have it automatically set on commits.
<br>
</blockquote>
<br>
This is what the proposal was about. I suggest the following action:
<br>
<br>
- I attach the proposal to issue #1256
<br>
</blockquote>
That seems like a good idea anyway.<br>
<blockquote
cite="midaea328ab0702280758t22186124na795dcdd7a268eca@mail.gmail.com"
type="cite">- everybody who is interested can add his/her username to
the CC list
<br>
</blockquote>
I have just added mine.<br>
<blockquote
cite="midaea328ab0702280758t22186124na795dcdd7a268eca@mail.gmail.com"
type="cite">- after an 8-week data-collection period, we can come back
to this
<br>
list and discuss the design again with those interested (including
<br>
those on the issue CC list)
<br>
- when the discussion comes to a conclusion, it'll the proposal may
<br>
need adjusting
<br>
- after adjusting, we'll want to find people wanting (to help) to
<br>
implement the change (I'll have at most time to help coordinate)
<br>
</blockquote>
For me personally it is not important if the issue will be resolved in
the future. I am making a migration module now, and I think after all
our stuff has been moved to Subversion the problem is not that grave
any more. The problem is that I migrate all files at the same time, so
all revisions will show to have been created at (more or less) the same
time. I want a file that was edited and committed in July 2004 in our
current code repository to be listed as committed in July 2004 in
Subversion. Later on, there may be small differences between the
modification time of a file and the commit time, but I don't think that
will be much of a problem. <br>
<br>
I think my migration problem may be overlooked as a user requirement
for this issue. But this migration problem might just as well be helped
if there was a switch like <b>--time</b> to the <b>svn commit</b>
command, making it possible to do a commit at another time than the
system time. But since there is no current issue for that change, I
fixed my attention on issue 1256 :-)<br>
<br>
Regards,<br>
<br>
Frans<br>
</body>
</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Erik Huelsmann <eh...@gmail.com>.
> I think maybe the best way to look at it is to look at how Subversion
> handles other metadata. I think the file name also is metadata, but that
> is a special case because Subversion uses this as the file identifier,
> right? If I change the name of the file using the OS, subversion has
> lost track of the file. So maybe it is better to look at the execute bit
> as an example of comparable metadata. It is stored in the property
> svn:execute. As far as I understand, subversion sets this property to
> the right value on every commit and sets the execute bit right when a
> file is copied from the repository. I can not check this, as I am on
> Windows XP, which does not have execute bits for files.
Some time ago, there was an enhancement proposal on the developers
list about versioning modified time metadata. If you're interested,
you can find it in the archives at
http://svn.haxx.se/dev/archive-2006-09/0492.shtml . There was no
implementation due to lack of (positive) reactions.
> I think this would probably the best way to handle the file modification
> time. Define a new reserved property, something like
> svn:modification-time and have it automatically set on commits.
This is what the proposal was about. I suggest the following action:
- I attach the proposal to issue #1256
- everybody who is interested can add his/her username to the CC list
- after an 8-week data-collection period, we can come back to this
list and discuss the design again with those interested (including
those on the issue CC list)
- when the discussion comes to a conclusion, it'll the proposal may
need adjusting
- after adjusting, we'll want to find people wanting (to help) to
implement the change (I'll have at most time to help coordinate)
> > Well, as you can see, versioning the modification time is not as
> > simple as it may sound.
> I certainly can imagine that it is not easy. If it was easy, maybe issue
> 1256 would have been resolved earlier.
Also, to the active developers this hasn't been much of an issue: each
scratches his/her own itches, but nobody seems to have this itch. I
can help coach someone wanting to jump into the codebase to help
develop this feature, but I don't have time to do more either.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Frans Knibbe <fr...@geodan.nl>.
Erik Huelsmann wrote:
>> I really don't know which tools use the time and which don't. There
>> probably are a few that use file modification time in some way. I know
>> for sure my brain uses the file modification time. For example, if I see
>> a file that was last modified in 1999, I know for sure that there aren't
>> any calls to Windows Vista functions in that code. Also, I sort files on
>> modification time a lot, just to see which files were recently edited.
>
> Right, but if we solve this issue, we'll need to determine whether a
> Subversion update to a file is a modification itself or not. Does an
> update to the file's metadata mean an update to the file itself? It's
> possible to change only metadata in a commit.
I think maybe the best way to look at it is to look at how Subversion
handles other metadata. I think the file name also is metadata, but that
is a special case because Subversion uses this as the file identifier,
right? If I change the name of the file using the OS, subversion has
lost track of the file. So maybe it is better to look at the execute bit
as an example of comparable metadata. It is stored in the property
svn:execute. As far as I understand, subversion sets this property to
the right value on every commit and sets the execute bit right when a
file is copied from the repository. I can not check this, as I am on
Windows XP, which does not have execute bits for files.
I think this would probably the best way to handle the file modification
time. Define a new reserved property, something like
svn:modification-time and have it automatically set on commits.
I don't know if you just change a file's execute bit (on a UNIX or Linux
system) this is reason for Subversion to create a new revision upon
commit. But in the case of the file modification time, it probably does
not matter because if the OS has changed this time, the file itself will
have been modified. So a new revision will be needed anyway.
>
> For example: when you merge a change into your - otherwise unchanged -
> working copy, which modification time do you assign to the file? That
> of the merge? That of the current time? Maybe the merge makes the file
> identical to some other file somewhere in the repository? What do we
> do then?
I think Subversion should always use the modification time as provided
by the Operating System.
>
> Well, as you can see, versioning the modification time is not as
> simple as it may sound.
I certainly can imagine that it is not easy. If it was easy, maybe issue
1256 would have been resolved earlier.
Cheers,
Frans
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Versioning Eudora email file trees doesn't work
Posted by Andy Levy <an...@gmail.com>.
On 2/27/07, Eric <sp...@scoot.netis.com> wrote:
>
> I tried creating a repository on our remote Subversion server in which to
> store email that's managed by Eudora on Windows (i.e. a file tree of files
> like .mbx, .toc, and various others).
>
> I imported the email file tree and then checked it out again, into another
> directory. Used Beyond Compare to verify that the files were all identical
> to the uploaded files, except for the file dates (yes, I also wish that
> Subversion would maintain the original last-modified date on files).
>
> Fired up Eudora, pointed it to the newly downloaded directory of files, and
> it crashed and burned, threw an exception, threatened to report me to
> Microsoft :-), all the stuff that Windoze programs typically do when they
> crash and burn.
>
> The only two differences between the original email file tree and the
> newly-downloaded working copy were the file dates and the newly-inserted
> .svn directories ... yes, I also wish that Subversion would maintain the
> original last-modified date on files ... oh, wait, I already said that. :-)
>
> Anybody have any idea why Eudora can't handle email trees stored in and
> retrieved from Subversion?
In a copy of your "good" Eudora mail directory, create an empty
directory named .svn. Does that cause a crash as well?
If it does (and maybe even if it doesn't), then I think your answers
lie with Eudora support, not Subversion.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Versioning Eudora email file trees doesn't work
Posted by Eric <sp...@scoot.netis.com>.
I tried creating a repository on our remote Subversion server in which to
store email that's managed by Eudora on Windows (i.e. a file tree of files
like .mbx, .toc, and various others).
I imported the email file tree and then checked it out again, into another
directory. Used Beyond Compare to verify that the files were all identical
to the uploaded files, except for the file dates (yes, I also wish that
Subversion would maintain the original last-modified date on files).
Fired up Eudora, pointed it to the newly downloaded directory of files, and
it crashed and burned, threw an exception, threatened to report me to
Microsoft :-), all the stuff that Windoze programs typically do when they
crash and burn.
The only two differences between the original email file tree and the
newly-downloaded working copy were the file dates and the newly-inserted
.svn directories ... yes, I also wish that Subversion would maintain the
original last-modified date on files ... oh, wait, I already said that. :-)
Anybody have any idea why Eudora can't handle email trees stored in and
retrieved from Subversion?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Erik Huelsmann <eh...@gmail.com>.
> I really don't know which tools use the time and which don't. There
> probably are a few that use file modification time in some way. I know
> for sure my brain uses the file modification time. For example, if I see
> a file that was last modified in 1999, I know for sure that there aren't
> any calls to Windows Vista functions in that code. Also, I sort files on
> modification time a lot, just to see which files were recently edited.
Right, but if we solve this issue, we'll need to determine whether a
Subversion update to a file is a modification itself or not. Does an
update to the file's metadata mean an update to the file itself? It's
possible to change only metadata in a commit.
For example: when you merge a change into your - otherwise unchanged -
working copy, which modification time do you assign to the file? That
of the merge? That of the current time? Maybe the merge makes the file
identical to some other file somewhere in the repository? What do we
do then?
Well, as you can see, versioning the modification time is not as
simple as it may sound.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Frans Knibbe <fr...@geodan.nl>.
Matt Sickler wrote:
> Sorry if I sound ignorant, but what does it really matter about the
> modification time of a file?
> What tools use it and why?
First of all, I think it is a matter of principle. I think no
information should be lost if I change the storage of my files. Of
course, you could argue that the file modification time is not really
part of the file itself, but some kind of metadata that can or can not
be kept in the file system. I tend to view the file modification date as
a file attribute, just like the name for example. I also do not want the
name of my files to change or to disappear when I copy or move them.
I really don't know which tools use the time and which don't. There
probably are a few that use file modification time in some way. I know
for sure my brain uses the file modification time. For example, if I see
a file that was last modified in 1999, I know for sure that there aren't
any calls to Windows Vista functions in that code. Also, I sort files on
modification time a lot, just to see which files were recently edited.
>
> On 2/26/07, *Frans Knibbe* < frans@geodan.nl <ma...@geodan.nl>>
> wrote:
>
> Hello,
>
> I have seen the subject pass by a few times in this list: subversion
> changes the file (modification) time to the commit time when you put a
> file in the repository. It is not possible to override this
> behaviour. I
> think is a fundamental problem with subversion. Whether I copy the
> file
> to another location, or compress it in an archive, or put it in a
> subversion repository, the time the file was last modified should not
> change. In other words: I think subversion should not tamper with
> files
> it stores. I want my files to come back exactly like they were when I
> put them in the repository. And that includes the time of the last
> modification.
>
> Now I have found that this problem is already an offcial issue. Its
> number is 1256
> (http://subversion.tigris.org/issues/show_bug.cgi?id=1256). But the
> issue has remained unresolved for a long time. I see it has now been
> postponed to version 1.5. I do hope this bug really gets solved soon.
>
> But I really can not wait for version 1.5. My organization is moving
> from another source control system to SVN and I have to write an
> importer. As it is now, it seems that all the files in the repository
> will wind up with the file time set to the moment they are handled by
> the importer. That means that a lot of useful and maybe vital
> information will get lost.
>
> Does anyone know of a way to put files in a subversion repository with
> the file time intact?
>
> Regards,
>
> Frans
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> <ma...@subversion.tigris.org>
> For additional commands, e-mail: users-help@subversion.tigris.org
> <ma...@subversion.tigris.org>
>
>
--
-------------------------------------
Frans Knibbe
Geodan S&R
President Kennedylaan 1
1079 MB Amsterdam (NL)
-------------------------------------
Tel: +31 (0)20 - 5711 347
Fax: +31 (0)20 - 5711 333
-------------------------------------
E-mail: frans.knibbe@geodan.nl
Website: www.geodan.nl
KvK-nummer: 33 247475
Disclaimer: www.geodan.nl/disclaimer
-------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is there really no way to keep the file modification time intact?
Posted by Matt Sickler <cr...@gmail.com>.
Sorry if I sound ignorant, but what does it really matter about the
modification time of a file?
What tools use it and why?
On 2/26/07, Frans Knibbe <fr...@geodan.nl> wrote:
>
> Hello,
>
> I have seen the subject pass by a few times in this list: subversion
> changes the file (modification) time to the commit time when you put a
> file in the repository. It is not possible to override this behaviour. I
> think is a fundamental problem with subversion. Whether I copy the file
> to another location, or compress it in an archive, or put it in a
> subversion repository, the time the file was last modified should not
> change. In other words: I think subversion should not tamper with files
> it stores. I want my files to come back exactly like they were when I
> put them in the repository. And that includes the time of the last
> modification.
>
> Now I have found that this problem is already an offcial issue. Its
> number is 1256
> (http://subversion.tigris.org/issues/show_bug.cgi?id=1256). But the
> issue has remained unresolved for a long time. I see it has now been
> postponed to version 1.5. I do hope this bug really gets solved soon.
>
> But I really can not wait for version 1.5. My organization is moving
> from another source control system to SVN and I have to write an
> importer. As it is now, it seems that all the files in the repository
> will wind up with the file time set to the moment they are handled by
> the importer. That means that a lot of useful and maybe vital
> information will get lost.
>
> Does anyone know of a way to put files in a subversion repository with
> the file time intact?
>
> Regards,
>
> Frans
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Re: Is there really no way to keep the file modification time intact?
Posted by Oliver Betz <li...@gmx.net>.
Frans Knibbe wrote:
[...]
> importer. As it is now, it seems that all the files in the repository
> will wind up with the file time set to the moment they are handled by
> the importer. That means that a lot of useful and maybe vital
not exactly. You can set the commit time to the modification time
when importing. See the perl script I posted 2006-10-27 in the thread
"Re: File date/time" for an example. And don't use ActiveState Perl
on Win32 since stat())->mtime inherited a bug from the Microsoft C
runtime.
I know that's not what you wanted, but maybe it's good enough for the
moment.
Nevertheless I also think that Subversion should support "mtime
keeping" natively.
Oliver
--
Oliver Betz, Muenchen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org