You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Andrew Webb <an...@gmail.com> on 2006/08/28 07:32:47 UTC
Keeping last-modified dates
Hello,
I'd like to add my voice to those calling for SVN to keep files'
last-modified date/times. I see you have this as being considered
for 1.5.
I'm trying to persuade my day job to move from VSS to another system.
Subversion is the first choice. I installed SVN and Tortoise over
the weekend, and have been busy playing and enjoying. I'd say that
the only basic feature that's missing (compared to our current VSS
use) is keeping files' last-modified times. These are important to
us.
Thanks for SVN and thanks for listening.
Andrew
Andrew Webb
Brighton, England
Re: Keeping last-modified dates
Posted by Mike Brenner <mi...@mitre.org>.
While many ftp servers do destroy the date,
you can tar/zip before ftp-ing, or you can rcp.
Under WINDOWS, the copy command does not destroy
the date modified (although it does destroy
the date created).
I disagree that modification dates "are fairly
useless". I often use modification data as
an quick method of guessing the contents of files.
In many configuration management systems
the modification date serves as important
metadata.
Changing the data on a file strongly
implies that the content has changed.
When software gets more complex, we
need to know whether we have the original
version of a file or the changed version.
Stability and debugging often depend on
having an original, unmodified file
for everything except the unit under test.
We should evolve subversion towards
keeping the modified date.
Gavin Lambert wrote:
> Quoth Andrew Webb <ma...@gmail.com>:
>> Speaking generally, I feel that any system that stores or
>> transmits or otherwise deals with files should honour the
>> contract of last-modified times. I.e. the time on a file
>> should be the last time its contents were changed. The fact
>> that I can import files into SVN and then export them and
>> lose that information seems wrong and unnecessary. To be
>> honest it's created a bad first impression, and I will have
>> to check with colleagues that this is lack is OK and that we
>> all still want to go ahead with Subversion. In all other
>> aspects Subversion seems excellent, and lives up to its
>> glowing reputation.
>
> When you 'svn export', you are creating new files, which, naturally
> enough, have both creation and modification dates set to the time
> they're created. Where's the problem?
>
> Uploading/downloading files from FTP or web servers results in the same
> behaviour. Even copy/move on the local OS can sometimes do the same
> thing.
>
> Modification dates are fairly useless as a measure of anything
> interesting. It doesn't take a lot to make a file change its date.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Marko Kaening <mk...@mch.osram.de>.
I brought this question up too, at least a year ago, or so.
Answers were quite the same: make etc...
But what gives me hope for the inclusion of an option to PRESERVE the
actual time of a checked-in file is that there is more than only one or
two requests for such a feature.
I understand arguments concerning make, though...
I personally use SVN not only for source code (mostly under Windows), but
also for ALMOST ALL my other files (DATs, DOCs, XLSs, PPTs and many more),
because I work on more than only one computer, but want to have my
up-to-date files on all of them with complete history...
In this situation I do miss this feature quite often. It's really sad to
get always the timestamp for the check-in time, instead of the actual
timestamp on all these files... It's a loss of information in some cases.
I would be really worthwhile to have this feature ***not only in a certain
branch of the subversion code*** but as a standard option for the normal
svn.
I vote for this!
;)
Marko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 29, 2006, at 13:19, Andrew Webb wrote:
>> When you 'svn export', you are creating new files, which, naturally
>> enough, have both creation and modification dates set to the time
>> they're created. Where's the problem?
>
> This is not natural for me.
> Thanks to Andreas for pointing out that it's a Microsoft thing. I'm a
> Windows developer and don't know what other OSes do.
Well, actually, before it was ever a Microsoft thing, it was an Apple
thing. Macs have done this since 1984.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Andrew Webb <an...@gmail.com>.
>
> When you 'svn export', you are creating new files, which, naturally
> enough, have both creation and modification dates set to the time
> they're created. Where's the problem?
This is not natural for me.
Thanks to Andreas for pointing out that it's a Microsoft thing. I'm a
Windows developer and don't know what other OSes do.
As a Windows user, I know exactly which operations will trash a file's
last-mod date, so I navigate around them. It's as natural as
breathing. Sending a file (even one) as an attachment to an email or
uploading to an FTP server? Whack it in a Zip file.
I think that SVN would feel more natural to us Windows people if it had
the option to honour the Windows file system's semantic contract for
last-modified dates.
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Keeping last-modified dates
Posted by Andreas Mahel <an...@ch.ibm.com>.
>
> When you 'svn export', you are creating new files, which, naturally
> enough, have both creation and modification dates set to the time
> they're created. Where's the problem?
I wouldn't really call it "naturally", it's just one possible way to
view things. It's the very low level, traditional Unix way of looking
at files - each inode is a separate entity and the system doesn't "care"
how it's been created. Also the "cp" command on my Linux box behaves
this way (the copied file will have a brand new last modification time).
However, the way many users perceive a file is different. If I create
a copy of a file, I would expect that not only the content itself is
duplicated but also some of the meta information, like the last time
when this content has been modified.
This is the way it is handled by Microsoft operating systems (and even
though I'm *not* a big MS lover, this one I find quite nice).
This behaviour is also the default for the KDE file manager Konqueror,
and even the "cp" command has its --preserve switch.
And since subversion can be seen as a versioned file system tree, and
checkout and commit as copy operations in the two directions, I'd
strongly vote for the possibility of keeping the modification date.
>
> Uploading/downloading files from FTP or web servers results in the same
> behaviour. Even copy/move on the local OS can sometimes do the same
> thing.
>
Actually, there exist ftp clients which keep the file modification time
when downloading files.
> Modification dates are fairly useless as a measure of anything
> interesting. It doesn't take a lot to make a file change its date.
Indeed, if someone wants to trick you by manipulating file modification
dates, he can do so very easily.
However, even subversion uses the last modified time to check if a file
has been modified...
just my €0.02
Andreas
RE: Keeping last-modified dates
Posted by Gavin Lambert <ga...@compacsort.com>.
Quoth Andrew Webb <ma...@gmail.com>:
> Speaking generally, I feel that any system that stores or
> transmits or otherwise deals with files should honour the
> contract of last-modified times. I.e. the time on a file
> should be the last time its contents were changed. The fact
> that I can import files into SVN and then export them and
> lose that information seems wrong and unnecessary. To be
> honest it's created a bad first impression, and I will have
> to check with colleagues that this is lack is OK and that we
> all still want to go ahead with Subversion. In all other
> aspects Subversion seems excellent, and lives up to its
> glowing reputation.
When you 'svn export', you are creating new files, which, naturally
enough, have both creation and modification dates set to the time
they're created. Where's the problem?
Uploading/downloading files from FTP or web servers results in the same
behaviour. Even copy/move on the local OS can sometimes do the same
thing.
Modification dates are fairly useless as a measure of anything
interesting. It doesn't take a lot to make a file change its date.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Werner Péter <Pe...@freemail.hu>.
> >Again no. cp will update the timestamp for you.
> >It has the same bug :-)
>
> Yes, the Unix "cp" command works like that, but copying a file in,
> say, the Mac OS X Finder does preserve the modification date, which
> is what Mac users expect, since it's been that way for 22 years so
> far and shows no signs of changing. (I don't know how Windows behaves
> in this regard.)
I just wanted to point out that the timestamp problem does not exists
for make users. Their tools support them. If Mac Finder does not, then
they use something else on Mac. I think there is a POSIX cp for Mac.
Rebuild-all guys will start studying make when the build takes 2 hours
even on distcc net.
Another example besides cp that has both options is tar (tar --touch).
For tar keeping mtime is the default but it's a backup tool. Perhaps it
is the same with fsvs. (And then we arrived to other file metadata:
permissions.)
I think it's clear that keeping modification time is a useful option.
The question is which is the better default value. I think not keeping
is better even for Windows (if you can do anytime svn up --no-touch to
get the last edit time).
WP
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 30, 2006, at 08:44, Peter Werner wrote:
> Again no. cp will update the timestamp for you.
> It has the same bug :-)
Yes, the Unix "cp" command works like that, but copying a file in,
say, the Mac OS X Finder does preserve the modification date, which
is what Mac users expect, since it's been that way for 22 years so
far and shows no signs of changing. (I don't know how Windows behaves
in this regard.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Peter Werner <l....@vasas.no-ip.org>.
> Well said. Seems to me that SVN's behaviour is defended here as a workaround
> for a problem that exists in collaborative s/w projects with/without a VCS
> system.
>
> (To the multitudes who pointed out my misunderstanding of Alice's part in
> the example scenario earlier: yes, it's a fair cop, I did misunderstand.
> However the problem still exists if you take the VCS out of the picture. If
> a colleague gives you a file that predates your last build, you'll have to
> let make know somehow, whether by touching the file or doing a make all.
> It's nowt to do with the VCS.)
Again no. cp will update the timestamp for you.
It has the same bug :-)
The problem is that svn is written in a compiled language, so they like
to support make.
cp does have a feature to preserve modification times, so it could be
the same with svn (but never default behaviour).
WP
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Keeping last-modified dates
Posted by Steve Fairhead <st...@fivetrees.com>.
John Burwell said:
>>
On Aug 29, 2006, at 12:34 PM, Steve Fairhead wrote:
> However: any time I do anything as drastic as checking files out of a
> VCS, or reverting, or including a replacement file from a colleague,
> or otherwise messing with the data that make uses to do a build, I'd
> expect to do a make clean or a touch.
>
> This is pretty basic stuff. It's not a reason for a VCS to throw data
> (in the form of timestamps) away.
For what it's worth, I likewise hate seeing information destroyed. Is it
really up to SVN to accommodate make's behavior in protracted what- if
scenarios?
<<
Well said. Seems to me that SVN's behaviour is defended here as a workaround
for a problem that exists in collaborative s/w projects with/without a VCS
system.
(To the multitudes who pointed out my misunderstanding of Alice's part in
the example scenario earlier: yes, it's a fair cop, I did misunderstand.
However the problem still exists if you take the VCS out of the picture. If
a colleague gives you a file that predates your last build, you'll have to
let make know somehow, whether by touching the file or doing a make all.
It's nowt to do with the VCS.)
>>
SVN is useful for all kinds of projects and document-management
applications. I could make sense out of a checkout/update option that uses
the check-in date as the last modified date on checked-out files, but a more
intuitive default would be to preserve the file exactly as it was
checked-in, which would include available metadata.
I'd like to see date clobbering provided as an option for users who spend a
lot of time dealing with the issues presented by make. The length and
verbosity of the discussions on this list is clear enough evidence that
people without an understanding of the make problem and its variants will
likewise have no understanding of SVN's current default date-clobbering
behavior. If SVN is to continue being promoted as a tool of versatility and
flexibility, supporting the most general use cases by not clobbering file
modification dates would be best, while allowing users with more specific
requirements to take advantage of the options as needed would maintain SVN's
convenience.
If nothing else, the behavior and its reasoning ought to be explained in the
documentation so that it comes as no confusing surprise while users are
attending to development outside of a make environment.
<<
Again, well said, and worth repeating.
Yes, there are problems with makefiles in group projects. It's not up to a
VCS to work around them. And a VCS is more generally useful than in just
those environments.
Steve
http://www.sfdesign.co.uk
http://www.fivetrees.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by John Burwell <jo...@galvnews.com>.
On Aug 29, 2006, at 12:34 PM, Steve Fairhead wrote:
> However: any time I do anything as drastic as checking files out of
> a VCS,
> or reverting, or including a replacement file from a colleague, or
> otherwise
> messing with the data that make uses to do a build, I'd expect to
> do a make
> clean or a touch.
>
> This is pretty basic stuff. It's not a reason for a VCS to throw
> data (in
> the form of timestamps) away.
For what it's worth, I likewise hate seeing information destroyed. Is
it really up to SVN to accommodate make's behavior in protracted what-
if scenarios?
SVN is useful for all kinds of projects and document-management
applications. I could make sense out of a checkout/update option that
uses the check-in date as the last modified date on checked-out
files, but a more intuitive default would be to preserve the file
exactly as it was checked-in, which would include available metadata.
I'd like to see date clobbering provided as an option for users who
spend a lot of time dealing with the issues presented by make. The
length and verbosity of the discussions on this list is clear enough
evidence that people without an understanding of the make problem and
its variants will likewise have no understanding of SVN's current
default date-clobbering behavior. If SVN is to continue being
promoted as a tool of versatility and flexibility, supporting the
most general use cases by not clobbering file modification dates
would be best, while allowing users with more specific requirements
to take advantage of the options as needed would maintain SVN's
convenience.
If nothing else, the behavior and its reasoning ought to be explained
in the documentation so that it comes as no confusing surprise while
users are attending to development outside of a make environment.
j
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 30, 2006, at 15:32, Duncan Murdoch wrote:
> Of course, this ignores the loss of information when importing an
> existing project into svn; is that the main concern?
That is my main concern, yes. I can deal with having just commit
times (as opposed to modification times) for files modified once the
project is in source control, but I was unhappy to lose the
modification time information for the years-old project I imported.
It's a moot point for me now as I accepted the information loss and
moved on, but for others just starting to use Subversion now, it
becomes an issue again.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 8/29/2006 6:52 PM, Ryan Schmidt wrote:
> On Aug 30, 2006, at 00:34, Gavin Lambert wrote:
>
>> For software source file control, at least, not preserving the
>> timestamps is definitely the way to go, as has already been explained
>> repeatedly. If you're using SVN for document versioning (which AFAIK
>> wasn't the original goal, but it's cool that it can be used that way)
>> then it *might* be desirable to preserve timestamps, if you don't
>> have a
>> better way of keeping track of documents. ('svn log' seems sufficient
>> to me.)
>
> Well, for *compiled* software projects using Makefiles or similar,
> Subversion's current behavior is useful. For me, it's not, as I write
> web sites in PHP, which is interpreted, not compiled. I don't use
> Makefiles.
I'm just curious: how does the current behaviour cause trouble in this
situation? In the only example I can think of (page reports "last
change" date) it seems to me that you really would want checkout or
update time shown, because that's when the page changed from the point
of view of someone using the web site. The developer can look at the
svn log to see when the page last changed in the repository.
Of course, this ignores the loss of information when importing an
existing project into svn; is that the main concern?
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Keeping last-modified dates
Posted by Steve Fairhead <st...@fivetrees.com>.
Ted Dennison said:
>>
Ryan Schmidt wrote:
>
> Well, for *compiled* software projects using Makefiles or similar,
> Subversion's current behavior is useful. For me, it's not, as I write
> web sites in PHP, which is interpreted, not compiled. I don't use
> Makefiles.
Personally, I think anyone doing web work should be using something like the
W3C validator ( http://validator.w3.org/ ) as their compiler. I haven't
tried automating this myself, but I'd imagine that make would be quite
helpful for this kind of thing.
<<
FWIW, I do quite a bit of web work, including PHP/MySQL. Everything I do
gets put through the W3C validator, and doesn't get published until it's
squeaky clean. But it's really more of a Lint than a compiler, and produces
no output as such (other than a webpage report, which I guess could be
stored, but manually). Also the workflow with PHP is a bit more complex than
with a source file - since it's dynamic, one has to capture the output and
submit that as a file to the validator.
Perhaps I'm missing your point?
Steve
(who has been known to use PHP/MySQL to generate compilable data-driven
.c/.h files...)
http://www.sfdesign.co.uk
http://www.fivetrees.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Ted Dennison <de...@ssd.fsi.com>.
Ryan Schmidt wrote:
>
> Well, for *compiled* software projects using Makefiles or similar,
> Subversion's current behavior is useful. For me, it's not, as I write
> web sites in PHP, which is interpreted, not compiled. I don't use
> Makefiles.
Personally, I think anyone doing web work should be using something like
the W3C validator ( http://validator.w3.org/ ) as their compiler. I
haven't tried automating this myself, but I'd imagine that make would be
quite helpful for this kind of thing.
--
T.E.D. Work - mailto:dennison@ssd.fsi.com
Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage - http://www.telepath.com/~dennison/Ted/TED.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 30, 2006, at 00:34, Gavin Lambert wrote:
> For software source file control, at least, not preserving the
> timestamps is definitely the way to go, as has already been explained
> repeatedly. If you're using SVN for document versioning (which AFAIK
> wasn't the original goal, but it's cool that it can be used that way)
> then it *might* be desirable to preserve timestamps, if you don't
> have a
> better way of keeping track of documents. ('svn log' seems sufficient
> to me.)
Well, for *compiled* software projects using Makefiles or similar,
Subversion's current behavior is useful. For me, it's not, as I write
web sites in PHP, which is interpreted, not compiled. I don't use
Makefiles.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Keeping last-modified dates
Posted by Gavin Lambert <ga...@compacsort.com>.
Quoth Steve Fairhead <ma...@fivetrees.com>:
> However: any time I do anything as drastic as checking files
> out of a VCS, or reverting, or including a replacement file
> from a colleague, or otherwise messing with the data that
> make uses to do a build, I'd expect to do a make clean or a touch.
Since when could 'svn update' be considered a drastic operation? It's
supposed to be routine -- something you do daily, if not more often.
For software source file control, at least, not preserving the
timestamps is definitely the way to go, as has already been explained
repeatedly. If you're using SVN for document versioning (which AFAIK
wasn't the original goal, but it's cool that it can be used that way)
then it *might* be desirable to preserve timestamps, if you don't have a
better way of keeping track of documents. ('svn log' seems sufficient
to me.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Keeping last-modified dates
Posted by Steve Fairhead <st...@fivetrees.com>.
Greg Thomas said:
>> Alice never edited a file. She simply checked it out on 1-Aug, compiled
it 3-Aug, and updated it on 4-Aug. Nothing was chucked away (although the
revision of 1-Aug was replaced with revision of 2-Aug), nothing was
reverted. <<
Ok, I understand your point.
However: any time I do anything as drastic as checking files out of a VCS,
or reverting, or including a replacement file from a colleague, or otherwise
messing with the data that make uses to do a build, I'd expect to do a make
clean or a touch.
This is pretty basic stuff. It's not a reason for a VCS to throw data (in
the form of timestamps) away.
Steve
http://www.sfdesign.co.uk
http://www.fivetrees.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Greg Thomas <th...@omc.bt.co.uk>.
On Tue, 29 Aug 2006 17:18:13 +0100, "Steve Fairhead"
<st...@fivetrees.com> wrote:
>Greg Thomas said:
>
>1-Aug: Alice checks out file foo.c, modification date 1-Aug.
>2-Aug: Bob modifies, commits foo.c
>3-Aug: Alice does a make. foo.c is compiled,
> creating foo.o timestamped 3-aug.
>4-Aug: Alice does a 'svn update'. foo.c arrives timestamped 2-Aug
> Alice does a make. foo.c is not compiled, despite being
> changed since the last compilation, as foo.c is timestamped
> 2-Aug (when Bob made the change), which is before foo.o was
> created (3-Aug).
><<
>
>This is fairly bogus. So Alice has edited a file, thrown it away, and
>reverted to an earlier version. With or without a VCS, this is (as I said
>earlier in another post) the sort of situation that breaks makefiles anyway.
>I'd do a make clean.
Alice never edited a file. She simply checked it out on 1-Aug,
compiled it 3-Aug, and updated it on 4-Aug. Nothing was chucked away
(although the revision of 1-Aug was replaced with revision of 2-Aug),
nothing was reverted.
Greg
--
This post represents the views of the author and does
not necessarily accurately represent the views of BT.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by William Nagel <bi...@stagelogic.com>.
On Aug 29, 2006, at 1:02 PM, Erik Huelsmann wrote:
> On 8/29/06, Steve Fairhead <st...@fivetrees.com> wrote:
>> Greg Thomas said:
>>
>> >>
>> On Tue, 29 Aug 2006 14:36:24 +0100, "Andrew Webb"
>> <an...@gmail.com> wrote:
>>
>> >As Steve Fairhead says in a recent, related thread: "one could argue
>> >just as hard for timestamps to be preserved *because* of makefiles".
>>
>> You could try, but I don't think you would be very successful. If you
>> preserve modification times, you fall in to the following trap:
>>
>> 1-Aug: Alice checks out file foo.c, modification date 1-Aug.
>> 2-Aug: Bob modifies, commits foo.c
>> 3-Aug: Alice does a make. foo.c is compiled,
>> creating foo.o timestamped 3-aug.
>> 4-Aug: Alice does a 'svn update'. foo.c arrives timestamped 2-Aug
>> Alice does a make. foo.c is not compiled, despite being
>> changed since the last compilation, as foo.c is timestamped
>> 2-Aug (when Bob made the change), which is before foo.o was
>> created (3-Aug).
>> <<
>>
>> This is fairly bogus. So Alice has edited a file, thrown it away, and
>> reverted to an earlier version. With or without a VCS, this is (as
>> I said
>> earlier in another post) the sort of situation that breaks
>> makefiles anyway.
>> I'd do a make clean.
>
> Well, it may break other VCS with makefiles, but this scenario works
> under Subversion, so, although make clean is a very good idea
> (always), there is not stricktly a need to with svn...
make clean is most certainly not "always" a very good idea. If I'm
working on a project with a three-hour build time (not at all
unlikely on a large C++ application with lots of templates) then it
would be a horrible idea for me to do a make clean every time I
updated from the repository.
-Bill
>
> bye,
>
> Erik.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 30, 2006, at 02:13, Duncan Murdoch wrote:
> On 8/29/2006 6:51 PM, Ryan Schmidt wrote:
>
>> On Aug 29, 2006, at 22:25, Duncan Murdoch wrote:
>>
>>> I would guess that it wouldn't be impossible to write wrapper
>>> scripts for svn that put the last mod date into a property just
>>> before a commit, and then modified the date based on that
>>> property just after a checkout or update. Tricky decisions
>>> would be what to do if an update resulted in a merge (presumably
>>> keep the merge time as last mod time), and recognizing cases
>>> where someone checked something in without using your script (so
>>> you'd need to fall back to the commit time).
>>
>> The problem with that is obviously the initial import: If I'm
>> importing a project that's been developed without version control
>> over the past two years, I don't suddenly want all of the files
>> in the project to have today's (or any other) modification date.
>> I want each file to remember the date on which that file was
>> modified. As has been explained by others, this is useful
>> information.
>
> Wouldn't my hypothetical script be able to add the property after
> importing? As far as I know, an import doesn't touch the files.
> Now, if you could do a substitution of a keyword %FILEMODDATE% in
> an auto-prop, this would be easy.
Oh, I see. You're thinking of a versioned property, like what's used
in the text-time branch. Yes, if you wrapped both commit/import and
update/checkout to do the right thing in either direction, it sounds
like that could work.
I was thinking of an unversioned property, specifically the svn:date
property of the revision, of which there's of course just one for the
entire revision. If you check in (or import) multiple files in a
single revision, they all have the same svn:date.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 8/29/2006 6:51 PM, Ryan Schmidt wrote:
> On Aug 29, 2006, at 22:25, Duncan Murdoch wrote:
>
>> I would guess that it wouldn't be impossible to write wrapper
>> scripts for svn that put the last mod date into a property just
>> before a commit, and then modified the date based on that property
>> just after a checkout or update. Tricky decisions would be what to
>> do if an update resulted in a merge (presumably keep the merge time
>> as last mod time), and recognizing cases where someone checked
>> something in without using your script (so you'd need to fall back
>> to the commit time).
>
> The problem with that is obviously the initial import: If I'm
> importing a project that's been developed without version control
> over the past two years, I don't suddenly want all of the files in
> the project to have today's (or any other) modification date. I want
> each file to remember the date on which that file was modified. As
> has been explained by others, this is useful information.
Wouldn't my hypothetical script be able to add the property after
importing? As far as I know, an import doesn't touch the files. Now,
if you could do a substitution of a keyword %FILEMODDATE% in an
auto-prop, this would be easy.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Keeping last-modified dates
Posted by Steve Fairhead <st...@fivetrees.com>.
Ryan Schmidt said:
>>
On Aug 29, 2006, at 22:25, Duncan Murdoch wrote:
> I would guess that it wouldn't be impossible to write wrapper scripts
> for svn that put the last mod date into a property just before a
> commit, and then modified the date based on that property just after a
> checkout or update. Tricky decisions would be what to do if an update
> resulted in a merge (presumably keep the merge time as last mod time),
> and recognizing cases where someone checked something in without using
> your script (so you'd need to fall back to the commit time).
The problem with that is obviously the initial import: If I'm importing a
project that's been developed without version control over the past two
years, I don't suddenly want all of the files in the project to have today's
(or any other) modification date. I want each file to remember the date on
which that file was modified. As has been explained by others, this is
useful information.
<<
Quite.
As a test, I've been doing just that, issue by issue, with an old, but still
on-going, project. Issue 1 was in May 1990. SVN doesn't know this.
The docs refer to SVN as being a file server with an added dimension: time.
Ironic, really ;).
(Lest I sound too harsh on this one point: I do appreciate the nature of
this enterprise, and value the work that's been put in. I'm just a kid with
a shiny new toy and a set of batteries that don't fit. Waaaah!)
Steve
http://www.sfdesign.co.uk
http://www.fivetrees.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 29, 2006, at 22:25, Duncan Murdoch wrote:
> I would guess that it wouldn't be impossible to write wrapper
> scripts for svn that put the last mod date into a property just
> before a commit, and then modified the date based on that property
> just after a checkout or update. Tricky decisions would be what to
> do if an update resulted in a merge (presumably keep the merge time
> as last mod time), and recognizing cases where someone checked
> something in without using your script (so you'd need to fall back
> to the commit time).
The problem with that is obviously the initial import: If I'm
importing a project that's been developed without version control
over the past two years, I don't suddenly want all of the files in
the project to have today's (or any other) modification date. I want
each file to remember the date on which that file was modified. As
has been explained by others, this is useful information.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 8/29/2006 2:15 PM, Steve Fairhead wrote:
> Erik Huelsmann said:
>
>>>
>> This is fairly bogus. So Alice has edited a file, thrown it away, and
>> reverted to an earlier version. With or without a VCS, this is (as I
>> said earlier in another post) the sort of situation that breaks makefiles
> anyway.
>> I'd do a make clean.
>
> Well, it may break other VCS with makefiles, but this scenario works under
> Subversion, so, although make clean is a very good idea (always), there is
> not stricktly a need to with svn...
> <<
>
> Yes, I realise that svn's current behaviour would favour this one scenario.
>
> However, I can offer plenty of counter arguments. Consider a project where
> some data files are built by some utilities, also within the project (the
> ./configure example has been used before). Whether or not the makefile
> figures it needs to rebuild the data files is currently a roll of the dice.
> In fact, the ability of the makefile to infer *any* kind of status of the
> component parts of some entity is entirely nuked by svn. As far as I can
> see, you have no choice *but* to do a make clean anyway.
>
> Like others have said, I'm fairly used to gaining a quick idea of the state
> of play of the project by sorting by date. Some files are current; some may
> not have changed in years. I'm currently looking at a source file folder in
> which some font files were built back in the 80s. The last-modified-date
> timestamp is a useful piece of data which svn simply discards. As I said
> earlier, this rules out svn for production use for me/us. Seems a shame. So
> near, yet so b0rked.
I would guess that it wouldn't be impossible to write wrapper scripts
for svn that put the last mod date into a property just before a commit,
and then modified the date based on that property just after a checkout
or update. Tricky decisions would be what to do if an update resulted
in a merge (presumably keep the merge time as last mod time), and
recognizing cases where someone checked something in without using your
script (so you'd need to fall back to the commit time).
Duncan Murdoch
>
> Steve
> http://www.sfdesign.co.uk
> http://www.fivetrees.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Keeping last-modified dates
Posted by Gavin Lambert <ga...@compacsort.com>.
Quoth Steve Fairhead <ma...@fivetrees.com>:
> However, I can offer plenty of counter arguments. Consider a
> project where some data files are built by some utilities,
> also within the project (the ./configure example has been
> used before). Whether or not the makefile figures it needs to
> rebuild the data files is currently a roll of the dice. In
> fact, the ability of the makefile to infer *any* kind of
> status of the component parts of some entity is entirely
> nuked by svn. As far as I can see, you have no choice *but*
> to do a make clean anyway.
Of course you do: don't put object files into version control in the
first place. There's no point in doing that, since they can always be
rebuilt from the source anyway. Since 'svn update' only updates the
timestamp if it does result in the file being changed, then the output
files will only get recompiled when they actually need to be; and since
it updates it to the current time, not the commit time, then they *will*
get built when they need to be (if it used the commit time then it'd be
semi-random whether they got built or not, which'd be a Bad Thing[tm]).
So in the 'configure' script case, if you have autoconf sources in your
project then you shouldn't commit the configure script itself.
Regardless of that, you shouldn't commit the config.status file or any
other output files that the configure script generates, either.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Keeping last-modified dates
Posted by Steve Fairhead <st...@fivetrees.com>.
Erik Huelsmann said:
>>
> This is fairly bogus. So Alice has edited a file, thrown it away, and
> reverted to an earlier version. With or without a VCS, this is (as I
> said earlier in another post) the sort of situation that breaks makefiles
anyway.
> I'd do a make clean.
Well, it may break other VCS with makefiles, but this scenario works under
Subversion, so, although make clean is a very good idea (always), there is
not stricktly a need to with svn...
<<
Yes, I realise that svn's current behaviour would favour this one scenario.
However, I can offer plenty of counter arguments. Consider a project where
some data files are built by some utilities, also within the project (the
./configure example has been used before). Whether or not the makefile
figures it needs to rebuild the data files is currently a roll of the dice.
In fact, the ability of the makefile to infer *any* kind of status of the
component parts of some entity is entirely nuked by svn. As far as I can
see, you have no choice *but* to do a make clean anyway.
Like others have said, I'm fairly used to gaining a quick idea of the state
of play of the project by sorting by date. Some files are current; some may
not have changed in years. I'm currently looking at a source file folder in
which some font files were built back in the 80s. The last-modified-date
timestamp is a useful piece of data which svn simply discards. As I said
earlier, this rules out svn for production use for me/us. Seems a shame. So
near, yet so b0rked.
Steve
http://www.sfdesign.co.uk
http://www.fivetrees.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Erik Huelsmann <eh...@gmail.com>.
On 8/29/06, Steve Fairhead <st...@fivetrees.com> wrote:
> Greg Thomas said:
>
> >>
> On Tue, 29 Aug 2006 14:36:24 +0100, "Andrew Webb"
> <an...@gmail.com> wrote:
>
> >As Steve Fairhead says in a recent, related thread: "one could argue
> >just as hard for timestamps to be preserved *because* of makefiles".
>
> You could try, but I don't think you would be very successful. If you
> preserve modification times, you fall in to the following trap:
>
> 1-Aug: Alice checks out file foo.c, modification date 1-Aug.
> 2-Aug: Bob modifies, commits foo.c
> 3-Aug: Alice does a make. foo.c is compiled,
> creating foo.o timestamped 3-aug.
> 4-Aug: Alice does a 'svn update'. foo.c arrives timestamped 2-Aug
> Alice does a make. foo.c is not compiled, despite being
> changed since the last compilation, as foo.c is timestamped
> 2-Aug (when Bob made the change), which is before foo.o was
> created (3-Aug).
> <<
>
> This is fairly bogus. So Alice has edited a file, thrown it away, and
> reverted to an earlier version. With or without a VCS, this is (as I said
> earlier in another post) the sort of situation that breaks makefiles anyway.
> I'd do a make clean.
Well, it may break other VCS with makefiles, but this scenario works
under Subversion, so, although make clean is a very good idea
(always), there is not stricktly a need to with svn...
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Andrew Webb <an...@gmail.com>.
So... it seems that for some this proposed feature of retaining files'
last-mod date is a must-have, and their processes, make procedures and
so on can cope. For others, the opposite is true.
Say for argument's sake it is implemented as an option in SVN 1.5.
What form should the option take? Is this a affects-whole-repository
flag? Or does it need to be more granular?
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 8/29/2006 12:18 PM, Steve Fairhead wrote:
> Greg Thomas said:
>
>>>
> On Tue, 29 Aug 2006 14:36:24 +0100, "Andrew Webb"
> <an...@gmail.com> wrote:
>
>>As Steve Fairhead says in a recent, related thread: "one could argue
>>just as hard for timestamps to be preserved *because* of makefiles".
>
> You could try, but I don't think you would be very successful. If you
> preserve modification times, you fall in to the following trap:
>
> 1-Aug: Alice checks out file foo.c, modification date 1-Aug.
> 2-Aug: Bob modifies, commits foo.c
> 3-Aug: Alice does a make. foo.c is compiled,
> creating foo.o timestamped 3-aug.
> 4-Aug: Alice does a 'svn update'. foo.c arrives timestamped 2-Aug
> Alice does a make. foo.c is not compiled, despite being
> changed since the last compilation, as foo.c is timestamped
> 2-Aug (when Bob made the change), which is before foo.o was
> created (3-Aug).
> <<
>
> This is fairly bogus. So Alice has edited a file, thrown it away, and
> reverted to an earlier version. With or without a VCS, this is (as I said
> earlier in another post) the sort of situation that breaks makefiles anyway.
> I'd do a make clean.
Alice never edited the file. She just checked it out, and used svn to
update it a few days later. svn moved the date forward from the
previous modification date in the repos (1-Aug) to the new modification
date in the repos (2-Aug). Unfortunately, the build system won't notice
that change, because it's only comparing to the date on foo.o (3-Aug).
I imagine even worse examples could be constructed if you allow Alice
and Bob to have inconsistent clocks.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
AW: RE: Keeping last-modified dates
Posted by Felix Gilcher <gi...@exozet.com>.
Steve Fairhead <ma...@fivetrees.com> schrieb am Dienstag, 29. August 2006 18:18:
> Greg Thomas said:
>
>>>
> On Tue, 29 Aug 2006 14:36:24 +0100, "Andrew Webb"
> <an...@gmail.com> wrote:
>
>> As Steve Fairhead says in a recent, related thread: "one could argue
>> just as hard for timestamps to be preserved *because* of makefiles".
>
> You could try, but I don't think you would be very successful. If you
> preserve modification times, you fall in to the following trap:
>
> 1-Aug: Alice checks out file foo.c, modification date 1-Aug.
> 2-Aug: Bob modifies, commits foo.c
> 3-Aug: Alice does a make. foo.c is compiled,
> creating foo.o timestamped 3-aug.
> 4-Aug: Alice does a 'svn update'. foo.c arrives timestamped 2-Aug
> Alice does a make. foo.c is not compiled, despite being
> changed since the last compilation, as foo.c is timestamped
> 2-Aug (when Bob made the change), which is before foo.o was
> created (3-Aug). <<
>
> This is fairly bogus. So Alice has edited a file, thrown it away, and
> reverted to an earlier version. With or without a VCS, this
> is (as I said
> earlier in another post) the sort of situation that breaks
> makefiles anyway.
> I'd do a make clean.
No, she did neither throw away any changes nor did she revert to an older version. It just happens that the newer version of foo.c was commited bevore she did a build in her working copy. After that she made an svn update, retrieving the newest version of foo.c but as it gets Bobs last-modified date the file is "older" than the compiled version, breaking the contract that "make" relies on. The way subversion behaves now, Alice would get a modification time of 08/04/2006 which honors the contract that make relies on (modified source files are supposed to be newer than the compiled versions).
Running a "make clean" for every build is only possible where build times are small enough or it will impact your productiveness.
>
> Steve
> http://www.sfdesign.co.uk
> http://www.fivetrees.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
felix
--
Felix Gilcher
Head of IT Development
Exozet Berlin GmbH
Rotherstraße 20
10245 Berlin
eMail: gilcher@exozet.com
URL: www.exozet.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Keeping last-modified dates
Posted by Steve Fairhead <st...@fivetrees.com>.
Greg Thomas said:
>>
On Tue, 29 Aug 2006 14:36:24 +0100, "Andrew Webb"
<an...@gmail.com> wrote:
>As Steve Fairhead says in a recent, related thread: "one could argue
>just as hard for timestamps to be preserved *because* of makefiles".
You could try, but I don't think you would be very successful. If you
preserve modification times, you fall in to the following trap:
1-Aug: Alice checks out file foo.c, modification date 1-Aug.
2-Aug: Bob modifies, commits foo.c
3-Aug: Alice does a make. foo.c is compiled,
creating foo.o timestamped 3-aug.
4-Aug: Alice does a 'svn update'. foo.c arrives timestamped 2-Aug
Alice does a make. foo.c is not compiled, despite being
changed since the last compilation, as foo.c is timestamped
2-Aug (when Bob made the change), which is before foo.o was
created (3-Aug).
<<
This is fairly bogus. So Alice has edited a file, thrown it away, and
reverted to an earlier version. With or without a VCS, this is (as I said
earlier in another post) the sort of situation that breaks makefiles anyway.
I'd do a make clean.
Steve
http://www.sfdesign.co.uk
http://www.fivetrees.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Mark Phippard <ma...@softlanding.com>.
"Andrew Webb" <an...@gmail.com> wrote on 08/29/2006 10:38:22 AM:
> > 1-Aug: Alice checks out file foo.c, modification date 1-Aug.
> > 2-Aug: Bob modifies, commits foo.c
> > 3-Aug: Alice does a make. foo.c is compiled,
> > creating foo.o timestamped 3-aug.
> > 4-Aug: Alice does a 'svn update'. foo.c arrives timestamped 2-Aug
> > Alice does a make. foo.c is not compiled, despite being
> > changed since the last compilation, as foo.c is timestamped
> > 2-Aug (when Bob made the change), which is before foo.o was
> > created (3-Aug).
>
> I understand.
>
> But shouldn't Alice have done an 'svn update' on the 3rd as well?
>
> I mean, if she does an update followed by a make on the 4th (seems
> reasonable), why only do a make on the 3rd?
Because maybe Alice only modified bar.c and she was just building the
project to test her changes. Now on the 4th she is going to commit bar.c
so she does an update prior to committing. She will get foo.c and any
other changes but some of those might not build because of the timestamps.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Erik Hemdal <er...@comprehensivepower.com>.
Greg Thomas wrote:
> On Tue, 29 Aug 2006 15:38:22 +0100, "Andrew Webb"
> <an...@gmail.com> wrote:
>
>
>>> 1-Aug: Alice checks out file foo.c, modification date 1-Aug.
>>> 2-Aug: Bob modifies, commits foo.c
>>> 3-Aug: Alice does a make. foo.c is compiled,
>>> creating foo.o timestamped 3-aug.
>>> 4-Aug: Alice does a 'svn update'. foo.c arrives timestamped 2-Aug
>>> Alice does a make. foo.c is not compiled, despite being
>>> changed since the last compilation, as foo.c is timestamped
>>> 2-Aug (when Bob made the change), which is before foo.o was
>>> created (3-Aug).
>>>
>> I understand.
>>
>> But shouldn't Alice have done an 'svn update' on the 3rd as well?
>>
>
> No. If she was working on a different bug fix to Bob, then there's no
> need for her to do a 'svn update' before each compile. Imagine the
> times I gave above where a minute apart rather than 1 day - I only
> used a day to make it easy to write. The problem still happens.
>
> Greg
>
I'm following this thread with great interest, because maybe I have a
problem I didn't know I had. Here's how I understand it
Alice modifies foo.c on 1-Aug.
She builds on 3-Aug.
She updates on 4-Aug, and either gets a conflicted file foo.c or throws
away her changes from 1-Aug. In either case, doesn't SVN tell her that
a file is updated or conflicted?
If the last-modification date is the "last-edited" date (2-Aug) then
foo.c is not recompiled when Alice makes.
If the last-modification date is the "checked-out" date (4-Aug) then
Alice's build will recompile foo.c, which sounds like it's what Alice wants.
Alice is in trouble because Bob committed before she built. If he had
committed after Alice built, she'd have no problem -- the
last-modification date would not matter either way. But she can't know
for certain unless she checks all the timestamps vs. the repository records.
If the last-modification time is the "checkout/update time", then the
updated files are always newer and a make will update the files. If
it's the"last-edited" time, it can give rise to this uncertain
situation. So I think this argues in favor of "last-checkout time"
instead of "last-edited time" from the standpoint of getting make to do
the right thing. It avoids having to 'touch' the files on checkout.
If I'm missing something, I ask forbearance, and for someone smarter to
set me straight.
I notice that in my repository, the date on the file is different from
what's in my working copy (I suppose it's the last-checked-in date in
the repo). Maybe we should be asking for a last-edited-date property
that can be set when a file is checked in? That way,
the last-modified-date can remain as is to help the make utility rebuild
changed files;
the last checked-in date can be in the repo for history, and
the new property can capture the edit date completely apart from what we
use to control rebuilds. Regardless of whether a file is older or
newer, if it's _different_ I want to rebuild it.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Greg Thomas <th...@omc.bt.co.uk>.
On Tue, 29 Aug 2006 15:38:22 +0100, "Andrew Webb"
<an...@gmail.com> wrote:
>> 1-Aug: Alice checks out file foo.c, modification date 1-Aug.
>> 2-Aug: Bob modifies, commits foo.c
>> 3-Aug: Alice does a make. foo.c is compiled,
>> creating foo.o timestamped 3-aug.
>> 4-Aug: Alice does a 'svn update'. foo.c arrives timestamped 2-Aug
>> Alice does a make. foo.c is not compiled, despite being
>> changed since the last compilation, as foo.c is timestamped
>> 2-Aug (when Bob made the change), which is before foo.o was
>> created (3-Aug).
>
>I understand.
>
>But shouldn't Alice have done an 'svn update' on the 3rd as well?
No. If she was working on a different bug fix to Bob, then there's no
need for her to do a 'svn update' before each compile. Imagine the
times I gave above where a minute apart rather than 1 day - I only
used a day to make it easy to write. The problem still happens.
Greg
--
This post represents the views of the author and does
not necessarily accurately represent the views of BT.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Andrew Webb <an...@gmail.com>.
> 1-Aug: Alice checks out file foo.c, modification date 1-Aug.
> 2-Aug: Bob modifies, commits foo.c
> 3-Aug: Alice does a make. foo.c is compiled,
> creating foo.o timestamped 3-aug.
> 4-Aug: Alice does a 'svn update'. foo.c arrives timestamped 2-Aug
> Alice does a make. foo.c is not compiled, despite being
> changed since the last compilation, as foo.c is timestamped
> 2-Aug (when Bob made the change), which is before foo.o was
> created (3-Aug).
I understand.
But shouldn't Alice have done an 'svn update' on the 3rd as well?
I mean, if she does an update followed by a make on the 4th (seems
reasonable), why only do a make on the 3rd?
I'm an SVN newcomer, so please excuse this question if it's
uninformed.
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Greg Thomas <th...@omc.bt.co.uk>.
On Tue, 29 Aug 2006 14:36:24 +0100, "Andrew Webb"
<an...@gmail.com> wrote:
>As Steve Fairhead says in a recent, related thread: "one could
>argue just as hard for timestamps to be preserved *because* of
>makefiles".
You could try, but I don't think you would be very successful. If you
preserve modification times, you fall in to the following trap:
1-Aug: Alice checks out file foo.c, modification date 1-Aug.
2-Aug: Bob modifies, commits foo.c
3-Aug: Alice does a make. foo.c is compiled,
creating foo.o timestamped 3-aug.
4-Aug: Alice does a 'svn update'. foo.c arrives timestamped 2-Aug
Alice does a make. foo.c is not compiled, despite being
changed since the last compilation, as foo.c is timestamped
2-Aug (when Bob made the change), which is before foo.o was
created (3-Aug).
Greg
--
This post represents the views of the author and does
not necessarily accurately represent the views of BT.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Henk Wissink <He...@Boschman.NL>.
Hello,
recently, I started the thread "How to convert specially set-up subdir tree into svn" to call for help on a few topics
of which one was to avoid loosing implicit information (like date/time stamps) in the process of filling a new svn
repository with the contents of my somewhat specially constructed version control directory tree I used for 15 years.
Now I see in new threads that there are more people concerned about the loss of that information. But for this
'makefile' issue I would like to bring up the following.
Let us say you check out a file dated 2 weeks ago. You build the whole thing from scratch. Later you 'update' your
working copy and that particular file is replaced by one dated 1 week ago. Although it is newer than your originally
checked-out file, it is still older than your derivative files created during the 'makeall' build process. So I think it
is not enough to simply have the last modified dates assigned by subversion to checked-out files. And assuring that the
next (selective) build will include that file is of no concern to subversion. Right?
(BTW: that is no issue for me personally: our projects are not that big and the computers quite fast so we always
rebuild the entire project.)
Best regards,
Henk Wissink
-----End------of------this------message-----
Andrew Webb wrote:
> As Steve Fairhead says in a recent, related thread: "one could
> argue just as hard for timestamps to be preserved *because* of
> makefiles".
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Andrew Webb <an...@gmail.com>.
> Well, there is the unofficial "text-time" branch of Subversion which
> does maintain this information. If maintaining this metadata is very
> important to you, you may want to build this branch of Subversion and
> use it instead of the official distribution.
To be honest, I'm not going to go there. I'd like to see an option to
preserve files' last-mod dates in SVN 1.5. Then us Windows users can
purge VSS from the planet forever. My intention is that this option
would be for the benefit of me, of all Windows users, and hopefully
also of SVN in reaching a wider, Windows audience.
> FWIW, I don't think the current Subversion behavior was created by
> accident or is considered a missing feature. Rather, I think it's
> intentional, to enable people to work with Makefiles in the standard
> way.
Umm... well, as a Windows developer, I would say it works the other way
round. As Steve Fairhead says in a recent, related thread: "one could
argue just as hard for timestamps to be preserved *because* of
makefiles".
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 29, 2006, at 08:20, Andrew Webb wrote:
> Speaking generally, I feel that any system that stores or transmits or
> otherwise deals with files should honour the contract of last-modified
> times. I.e. the time on a file should be the last time its contents
> were changed. The fact that I can import files into SVN and then
> export them and lose that information seems wrong and unnecessary.
> To be honest it's created a bad first impression, and I will have to
> check with colleagues that this is lack is OK and that we all still
> want to go ahead with Subversion. In all other aspects Subversion
> seems excellent, and lives up to its glowing reputation.
Well, there is the unofficial "text-time" branch of Subversion which
does maintain this information. If maintaining this metadata is very
important to you, you may want to build this branch of Subversion and
use it instead of the official distribution.
http://svn.collab.net/repos/svn/branches/meta-data-versioning/
FWIW, I don't think the current Subversion behavior was created by
accident or is considered a missing feature. Rather, I think it's
intentional, to enable people to work with Makefiles in the standard
way. I'm not sure I can explain it entirely correctly because I don't
write compiled software, but IIRC, Makefiles rely on last modified
dates, and won't compile something unless it's newer than the last
time that thing was compiled. Updating a working copy and getting
files that aren't modified "now", therefore, causes problems getting
all the new bits compiled properly.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Andrew Webb <an...@gmail.com>.
Ryan,
Thanks for your suggestions.
Speaking generally, I feel that any system that stores or transmits or
otherwise deals with files should honour the contract of last-modified
times. I.e. the time on a file should be the last time its contents
were changed. The fact that I can import files into SVN and then
export them and lose that information seems wrong and unnecessary.
To be honest it's created a bad first impression, and I will have to
check with colleagues that this is lack is OK and that we all still
want to go ahead with Subversion. In all other aspects Subversion
seems excellent, and lives up to its glowing reputation.
Thanks.
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 28, 2006, at 20:59, Andrew Webb wrote:
> Apart from the fact that it's of general interest to me when a code
> file was last modified (something that seems to get lost when you
> import the files into an SVN repository), my main use-case is that of
> copying only those files that have changed to a virtual machine, where
> I build installers. The reason for this is slow operation of the VM,
> and slow access of the VM to the network. I really have to keep the
> number of file copies down to a minimum. Now some of the files that
> get copied are DLLs and EXEs, and thus not under source code control
> in themselves. But other files are data files, and currently I rely
> on their last-modified dates to copy only those that have changed
> since a certain date. This is how I work with VSS as our source code
> control system. Of course it may be the case that the use of SVN may
> afford a different style of working that means I don't have to rely on
> last-modified dates.
You could simply check out a working copy of the project on the
virtual machine, if it has access to the network. Then just "svn up"
when you want to update to the latest version. Not only will
Subversion not re-download all files, it won't even download just the
changed files -- it'll download only the *changes* to the files, so
it's extremely efficient.
> Another use-case is receiving data files from, and sending data files
> to, people who are external to the developer team (e.g. marketing
> folks, or even clients) who don't use source code control. Although
> documents should have in-document revision histories, sometimes this
> doesn't happen with the desired accuracy. In this case last-modified
> dates on the files can prove invaluable in checking which is the most
> up-to-date copy of a document. This is why we're careful to always
> Zip-compress files, even a single file that would be considered as a
> safe email attachment: Zips maintain the last-modified dates.
In-document revision histories (change logs) are not recommended with
Subversion, for reasons explained here:
http://subversion.tigris.org/faq.html#log-in-source
As for your desire for modification dates for this reason, I'm not
sure what to suggest. Once you get going with the project, any time
you check in, the revision will have the date and time at which you
checked in. Which is just about as good as a modification date and
time, so long as you don't wait to long between modification and
checkin. And you can use the "use-commit-times" option so that, when
you check out or update, you don't get the current date and time but
the commit time. Maybe that's good enough for what you need.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Andrew Webb <an...@gmail.com>.
On 8/28/06, Erik Huelsmann <eh...@gmail.com> wrote:
> On 8/28/06, Andrew Webb <an...@gmail.com> wrote:
> >
> > I'd like to add my voice to those calling for SVN to keep files'
> > last-modified date/times. I see you have this as being considered
> > for 1.5.
> >
> > I'm trying to persuade my day job to move from VSS to another system.
> > Subversion is the first choice. I installed SVN and Tortoise over
> > the weekend, and have been busy playing and enjoying. I'd say that
> > the only basic feature that's missing (compared to our current VSS
> > use) is keeping files' last-modified times. These are important to
> > us.
>
> Hi. Could you elaborate a bit more on the subject: why are they
> important? What do you do with them?
>
> Subversion extentions are developed by carefully considering the user
> benefit/development-or-maintenance cost balance. We have many feature
> requests and have implemented some little-used features
> (use-commit-times) in the past, but they end up being poorly
> maintained or hard to maintain.
>
> So: I can do nothing but value your request, but at the same time ask
> for a larger contribution: tell us your use-case please!
>
> bye,
>
> Erik.
>
Hi Erik,
Apart from the fact that it's of general interest to me when a code
file was last modified (something that seems to get lost when you
import the files into an SVN repository), my main use-case is that of
copying only those files that have changed to a virtual machine, where
I build installers. The reason for this is slow operation of the VM,
and slow access of the VM to the network. I really have to keep the
number of file copies down to a minimum. Now some of the files that
get copied are DLLs and EXEs, and thus not under source code control
in themselves. But other files are data files, and currently I rely
on their last-modified dates to copy only those that have changed
since a certain date. This is how I work with VSS as our source code
control system. Of course it may be the case that the use of SVN may
afford a different style of working that means I don't have to rely on
last-modified dates.
Another use-case is receiving data files from, and sending data files
to, people who are external to the developer team (e.g. marketing
folks, or even clients) who don't use source code control. Although
documents should have in-document revision histories, sometimes this
doesn't happen with the desired accuracy. In this case last-modified
dates on the files can prove invaluable in checking which is the most
up-to-date copy of a document. This is why we're careful to always
Zip-compress files, even a single file that would be considered as a
safe email attachment: Zips maintain the last-modified dates.
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Keeping last-modified dates
Posted by Erik Huelsmann <eh...@gmail.com>.
On 8/28/06, Andrew Webb <an...@gmail.com> wrote:
>
> I'd like to add my voice to those calling for SVN to keep files'
> last-modified date/times. I see you have this as being considered
> for 1.5.
>
> I'm trying to persuade my day job to move from VSS to another system.
> Subversion is the first choice. I installed SVN and Tortoise over
> the weekend, and have been busy playing and enjoying. I'd say that
> the only basic feature that's missing (compared to our current VSS
> use) is keeping files' last-modified times. These are important to
> us.
Hi. Could you elaborate a bit more on the subject: why are they
important? What do you do with them?
Subversion extentions are developed by carefully considering the user
benefit/development-or-maintenance cost balance. We have many feature
requests and have implemented some little-used features
(use-commit-times) in the past, but they end up being poorly
maintained or hard to maintain.
So: I can do nothing but value your request, but at the same time ask
for a larger contribution: tell us your use-case please!
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org