You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by tr...@clayst.com on 2004/11/29 19:02:07 UTC
Timestamp Issues
I'm confused about timestamps ... it appears from the following
sentence:
Normally your working copy files have timestamps that reflect the
last time they were touched by any process, whether that be your
own editor or by some svn subcommand.
that svn might be setting timestamps on checkout to the time of
checkout. Is that right? I have two branch directories that appear to
reflect this, or perhaps to reflect the time the directory was renamed.
What I want is for the file system timestamp to reflect the time I
changed the file with the editor, not the time it was checked in or
out, or when the directory it's in was renamed. In other words, when I
check out a file I want it to have the same filesystem timestamp it had
when I committed that revision. Can I do this with Subversion? I
would have expected it to be the default, yet the branch directories I
created seem to suggest otherwise.
Thanks for any info,
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Issues
Posted by tr...@clayst.com.
On 29 Nov 2004 Patrick Smears wrote:
> No, that is not currently possible with just subversion (although it's
> possible using, for example, scripts that make use of properties to store
> the relevant times).
I cooked up a couple of 4NT batch files which will set and get a
"timestamp" property and do the right thing with it, using the output
from svn list -R as a base. This is slow as it runs against all files,
it would need to parse output from svnlook and have some more
intelligence to be useful, but the concept does work.
If I were to do it I think the best thing to do would be to write
custom scripts to invoke svn that would see if the command in question
could modify the repository or retrieve something from it, then use
svnlook to see what was changed and go from there. I think I could
also set the property in a pre-commit hook script, but I'd still have
to write a custom interface to at least checkout and update to read the
property and set the timestamp.
It's definitely doable, but not what I'd call simple!
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Issues
Posted by tr...@clayst.com.
On 30 Nov 2004 Michael Stevens wrote:
> a) Every time you deploy, you checkout a new copy of your
> repository, and then FTP it to the server?
Well, I was considering something like that but I still don't have a
working repository, so we're not there yet. It's slightly complicated
by the existence of main development and bug fix branches, so sometimes
they will get merged and sometimes we'd just be deploying off the bug
fix branch. But I don't think that is material to your strategy.
> b) The FTP client is checking the timestamps on your fresh working
> copy, vs the timestamps on the server?
Yes. What happens is that the server timestamps are set on the upload
(though we could disable that) so the client sees everything that has
been modified since the last deployment as new. Truth is it is not
comparing "last content modification" dates but rather comparing "last
content modification" on the development system to "last upload" on the
server. I also sometimes have to adjust for timezone differences
(depending on the project and where the server is).
> c) The timestamps of the newly checked out repository are all newer
> than the timestamps on the server (being that the timestamps have
> all been set to what was recently checked out), so the entire working
> copy is being copied, rather than the changes?
Yes ... "would be" rather than "are" / "is", since it's not live yet.
> If that is the issue, then perhaps I can suggest a simple solution.
> Maintain a working copy of the repository (lets call this the
> staging copy), don't delete it when you've done deploying. Don't
> checkout a new copy each time. Rather, simply run 'svn update' on
> your staging copy. Only new files will be updated, so timestamps
> should only change on the files that have actually been updated.
> After that FTP your staging copy to your server.
OK, so I am still giving up having the timestamp match the content
modification, but at least I will have a timestamp that matches the
last update time instead of a checkout time. Right?
I like the solution, I have to sort out whether that's a good tradeoff
but it might be.
Thanks!
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Issues
Posted by Christopher Ness <ch...@nesser.org>.
Before we get to the meat, I don't know if you saw this in the client
config (note client, not server) or not [~/.subversion/config]:
### Set use-commit-times to make checkout/update/switch/revert
### put last-committed timestamps on every file touched.
# use-commit-times = yes
May be useful for you to lock last changed timestamp to commit times.
On Mon, 2004-29-11 at 21:55 -0500, trlists@clayst.com wrote:
> On 29 Nov 2004 Christopher Ness wrote:
> > Do you _have_ to use that tool or can you do some scripting in SVN to
> > deploy changes into production?
>
> Well yes, but I'd rather not! I'm also used to simply observing the
> timestamps (as in "well, I probably don't have to check there to see if
> that's where the newly created problem is, because that file hasn't
> changed since last July"). I shouldn't be reworking my whole work
> environment to meet the needs of the VCS -- it should be a tool, not a
> framework that defines the development setup (though these days, many
> of the tools behave like wannbe frameworks! :-)).
I like simple things too, I like them a lot! But now that I'm a little
more comfortable with subversion and *nix, these things are becoming
more trivial to pin down.
To comment on your example above about someone breaking the build:
For example if someone committed a file that broke something in the past
- lets say day - on the subversion server you just need to ask for the
logs for those times. You can do this example for yourself by checking
out the trunk of the SVN project.
Of course you could use this method to find all the changed files in
July, but there could likely be duplicates, use `sort` and `uniq` to get
rid of those.
WARNING: Someone may have a better method of discovering the files that
changed between two time periods. Please speak up as I'd like to know
too! Windows users can get a GNU/bash environment apparently.
[nesscg@woman trunk]$ svn info Path: .
URL: http://svn.collab.net/repos/svn/trunk
Repository UUID: 65390229-12b7-0310-b90b-f21a5aa7ec8e
Revision: 12092
<snip> Below might be interesting to you</snip>
Last Changed Date: 2004-11-29 20:56:04 -0500 (Mon, 29 Nov 2004)
Properties Last Updated: 2004-09-15 13:26:31 -0400 (Wed, 15 Sep 2004)
[nesscg@woman trunk]$ svn diff -r{2004-11-28}:{"2004-11-29 22:30"} |
grep "^Index"
Index: build.conf
Index: www/project_links.html
Index: notes/fs_dumprestore.txt
Index: subversion/include/svn_ctype.h
Index: subversion/include/svn_utf.h
<snip> More file paths are output here </snip>
Index: doc/translations/spanish/book/ch04.xml
Index: doc/translations/spanish/glosario_traduccion
Index: doc/book/TODO
[nesscg@woman trunk]$
Now you have a hitlist to look through for the buggy code. Some you can
probably ignore right away. For example if the problem wasn't in the
book source.
> The FTP client isn't a "middle man" it's a tool appropriate for the
> job. One of the things I like about Subversion is that it doesn't try
> to be something more than a VCS -- but I wish (based on admittedly very
> limited experience) that it didn't make quite so many assumptions about
> how VCS users operate. Of course it has to make some -- I just want
> the ones that don't work for *me* left out :-).
Now you need to get the changed files onto the production server. I'm
going to leave that as a exercise for the reader as there are many ways
of doing that task.
As an aside:
I find SVN is very much a Unix based product in that you should be able
to take the output from it and pipe it into another program to get some
work done. I like that ability.
Have fun!
Chris
Re: Timestamp Issues
Posted by Scott Lawrence <sl...@pingtel.com>.
On Tue, 2004-11-30 at 16:35 +1300, Michael Stevens wrote:
> Hello, just thought I'd jump in here... Am I right in assuming that:
>
> a) Every time you deploy, you checkout a new copy of your repository,
> and then FTP it to the server?
> b) The FTP client is checking the timestamps on your fresh working
> copy, vs the timestamps on the server?
> c) The timestamps of the newly checked out repository are all newer
> than the timestamps on the server (being that the timestamps have all
> been set to what was recently checked out), so the entire working copy
> is being copied, rather than the changes?
>
> If that is the issue, then perhaps I can suggest a simple solution.
> Maintain a working copy of the repository (lets call this the staging
> copy), don't delete it when you've done deploying. Don't checkout a
> new copy each time. Rather, simply run 'svn update' on your staging
> copy. Only new files will be updated, so timestamps should only
> change on the files that have actually been updated. After that FTP
> your staging copy to your server.
>
> We use this exact solution here at work (albiet with a complex file
> comparision tool someone hacked up in Perl, rather than a simple FTP
> client), and it works just fine.
We go one step further than that - we have a working copy on the web
server that is updated by a hook script whenever something is checked
in, and a 'make' is run in it (to do xslt transforms to create the
static web pages). The output files from that transform are visible as
a 'staging' server, and then a cgi on the main site uses rsync to move
any changed files to the real web site.
Each step only touches files that have actually changed, and all
dependencies are accounted for.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Issues
Posted by Michael Stevens <fr...@gmail.com>.
Hello, just thought I'd jump in here... Am I right in assuming that:
a) Every time you deploy, you checkout a new copy of your repository,
and then FTP it to the server?
b) The FTP client is checking the timestamps on your fresh working
copy, vs the timestamps on the server?
c) The timestamps of the newly checked out repository are all newer
than the timestamps on the server (being that the timestamps have all
been set to what was recently checked out), so the entire working copy
is being copied, rather than the changes?
If that is the issue, then perhaps I can suggest a simple solution.
Maintain a working copy of the repository (lets call this the staging
copy), don't delete it when you've done deploying. Don't checkout a
new copy each time. Rather, simply run 'svn update' on your staging
copy. Only new files will be updated, so timestamps should only
change on the files that have actually been updated. After that FTP
your staging copy to your server.
We use this exact solution here at work (albiet with a complex file
comparision tool someone hacked up in Perl, rather than a simple FTP
client), and it works just fine.
On Mon, 29 Nov 2004 21:55:02 -0500, trlists@clayst.com
<tr...@clayst.com> wrote:
> On 29 Nov 2004 Christopher Ness wrote:
>
> > Ah, I get it! You have a tool that doesn't "deploy" files that haven't
> > changed.
>
> Yes. AN FTP client, in this case. It's a simple process.
>
> > Do you _have_ to use that tool or can you do some scripting in SVN to
> > deploy changes into production?
>
> Well yes, but I'd rather not! I'm also used to simply observing the
> timestamps (as in "well, I probably don't have to check there to see if
> that's where the newly created problem is, because that file hasn't
> changed since last July"). I shouldn't be reworking my whole work
> environment to meet the needs of the VCS -- it should be a tool, not a
> framework that defines the development setup (though these days, many
> of the tools behave like wannbe frameworks! :-)).
>
> > > It's too bad there's no way to select this as an option -- it appears
> > > that it's going to make my use of Subversion a lot more difficult.
> >
> > That's one point of view. But with come creative juices (mostly coffee)
> > you might be able to take out the middle man.
>
> The FTP client isn't a "middle man" it's a tool appropriate for the
> job. One of the things I like about Subversion is that it doesn't try
> to be something more than a VCS -- but I wish (based on admittedly very
> limited experience) that it didn't make quite so many assumptions about
> how VCS users operate. Of course it has to make some -- I just want
> the ones that don't work for *me* left out :-).
>
>
>
> --
> Tom
>
> ---------------------------------------------------------------------
> 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: Timestamp Issues
Posted by tr...@clayst.com.
On 29 Nov 2004 Christopher Ness wrote:
> Ah, I get it! You have a tool that doesn't "deploy" files that haven't
> changed.
Yes. AN FTP client, in this case. It's a simple process.
> Do you _have_ to use that tool or can you do some scripting in SVN to
> deploy changes into production?
Well yes, but I'd rather not! I'm also used to simply observing the
timestamps (as in "well, I probably don't have to check there to see if
that's where the newly created problem is, because that file hasn't
changed since last July"). I shouldn't be reworking my whole work
environment to meet the needs of the VCS -- it should be a tool, not a
framework that defines the development setup (though these days, many
of the tools behave like wannbe frameworks! :-)).
> > It's too bad there's no way to select this as an option -- it appears
> > that it's going to make my use of Subversion a lot more difficult.
>
> That's one point of view. But with come creative juices (mostly coffee)
> you might be able to take out the middle man.
The FTP client isn't a "middle man" it's a tool appropriate for the
job. One of the things I like about Subversion is that it doesn't try
to be something more than a VCS -- but I wish (based on admittedly very
limited experience) that it didn't make quite so many assumptions about
how VCS users operate. Of course it has to make some -- I just want
the ones that don't work for *me* left out :-).
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Issues
Posted by Christopher Ness <ch...@nesser.org>.
On Mon, 2004-29-11 at 20:40 -0500, Tom Rawson wrote:
> On 29 Nov 2004 Patrick Smears wrote:
> >
> > The reason for the default behaviour is that any other behaviour tends to
> > confuse utilities like 'make' that depend on timestamps on files to
> > determine which file has been changed most recently (e.g. if someone else
> > commits a change to a file, then I do a 'make', then I update my WC to
> > pull in their change - I want the changed file to have the time of my
> > update, not the time of their commit or the time they changed the file, or
> > else 'make' won't know to rebuild targets that depended on the changed
> > file...). Since 'make'-like build systems are a very common use case for
> > Subversion, this is what the developers have implemented.
>
> Fair enough. The approach you described makes a lot of sense for a
> multiprogrammer C project. BUT the exact same requirement -- using
> timestamps to drive utilities that determine what files have been
> changed -- argues for the opposite approach when the code is not
> compiled and deployment uses the timestamps on the source code. In the
> projects for which I need Subversion right now, the code is all
> interpreted (PHP, JavaScript, HTML, CSS) and is deployed to the web.
> The deployment uses timestamps to determine what has changed since the
> last time the web server was updated.
I'm not sure what your term "deployment" means, but if you want to see
what has changed shouldn't that be subversions job?
Why not create a tag for every release you do to production and then do
a diff against the latest tag? This will show you what has changed and
will not be dependant on time stamps.
> I can see that if original timestamps that show "last modification" are
> preserved it breaks the make utilities -- but if they are not, it
> breaks timestamp-based deployment utilities for code that doesn't need
> a make step.
Ah, I get it! You have a tool that doesn't "deploy" files that haven't
changed. Do you _have_ to use that tool or can you do some scripting in
SVN to deploy changes into production?
> It's too bad there's no way to select this as an option -- it appears
> that it's going to make my use of Subversion a lot more difficult.
That's one point of view. But with come creative juices (mostly coffee)
you might be able to take out the middle man.
Cheers,
Chris
Re: Timestamp Issues
Posted by Scott Palmer <sc...@digital-rapids.com>.
On Nov 29, 2004, at 8:40 PM, Tom Rawson wrote:
> Fair enough. The approach you described makes a lot of sense for a
> multiprogrammer C project. BUT the exact same requirement -- using
> timestamps to drive utilities that determine what files have been
> changed -- argues for the opposite approach when the code is not
> compiled and deployment uses the timestamps on the source code.
I agree with this. The option to preserve true modification time
should be available. (And preferrably built-in, not up to some wrapper
script hacking.)
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Issues
Posted by Tom Rawson <tr...@clayst.com>.
On 29 Nov 2004 Patrick Smears wrote:
> > What I want is for the file system timestamp to reflect the time I
> > changed the file with the editor, not the time it was checked in or
> > out, or when the directory it's in was renamed. In other words, when I
> > check out a file I want it to have the same filesystem timestamp it had
> > when I committed that revision. Can I do this with Subversion?
>
> No, that is not currently possible with just subversion (although it's
> possible using, for example, scripts that make use of properties to store
> the relevant times).
Hmmm, OK, not the answer I wanted but I'll look in the book to see if I
can sort this out, and come back if I can't. Thanks.
> The reason for the default behaviour is that any other behaviour tends to
> confuse utilities like 'make' that depend on timestamps on files to
> determine which file has been changed most recently (e.g. if someone else
> commits a change to a file, then I do a 'make', then I update my WC to
> pull in their change - I want the changed file to have the time of my
> update, not the time of their commit or the time they changed the file, or
> else 'make' won't know to rebuild targets that depended on the changed
> file...). Since 'make'-like build systems are a very common use case for
> Subversion, this is what the developers have implemented.
Fair enough. The approach you described makes a lot of sense for a
multiprogrammer C project. BUT the exact same requirement -- using
timestamps to drive utilities that determine what files have been
changed -- argues for the opposite approach when the code is not
compiled and deployment uses the timestamps on the source code. In the
projects for which I need Subversion right now, the code is all
interpreted (PHP, JavaScript, HTML, CSS) and is deployed to the web.
The deployment uses timestamps to determine what has changed since the
last time the web server was updated.
I can see that if original timestamps that show "last modification" are
preserved it breaks the make utilities -- but if they are not, it
breaks timestamp-based deployment utilities for code that doesn't need
a make step.
It's too bad there's no way to select this as an option -- it appears
that it's going to make my use of Subversion a lot more difficult.
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Issues
Posted by tr...@clayst.com.
Another thought on this -- is the current behavior (timestamps updated
on checkout or update) a requirement for some part of the internal
finctioning of Subversion, so that it would require a lot of internal
rework to make that optional? Or is it more a feature that happens to
work one way now but that could easily be made to work (optionally)
another way without disrupting internal structures and behaviors?
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Issues
Posted by Scott Palmer <sc...@2connected.org>.
On Nov 29, 2004, at 4:44 PM, Kris Deugau wrote:
> Patrick Smears wrote:
> Hmmm. I think you've got this scenario a little backwards. If you
> make
> changes to a source file, and commit it; then someone else makes
> changes elsewhere (changes that don't interfere with yours) and
> commits,
> *that* version of the file is the "correct" (newer) one - not the one
> in
> your local WC.
>
> When you svn up, if someone has committed changes to a file, that file
> should have a newer timestamp either way - and if the changes from
> someone else's change conflict with changes you've made since your
> commit, the timestamp on your file will be newer still once you've
> resolved that.
>
I think the case that SVN is trying to handle is this:
File A.c has a timestamp of 0:45
User A modifies A.c , it ends up with a timestamp of 1:00 in his
working copy
User A hasn't checked in A.c yet.
User B does an update at 1:01
this gets a working copy with A.c and it's previous timestamp 0:45
User B builds and A.c is compiled to A.o which gets the current
timestamp of 1:02
User A checks in the new A.c with the 1:00 time stamp.
User B updates and gets the new A.c with a timestamp of 1:00
User B builds, but A.o is not rebuilt because 'make' thinks A.o is
already up to date.
User B now has a broken build.
By modifying files on checkout/update subversion makes sure that files
that change in a working copy get re-built by tools like 'make'
Regards,
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Issues
Posted by Patrick Smears <pa...@ensoft.co.uk>.
On Mon, 29 Nov 2004, Kris Deugau wrote:
> Patrick Smears wrote:
> > The reason for the default behaviour is that any other behaviour
> > tends to confuse utilities like 'make' that depend on timestamps on
> > files to determine which file has been changed most recently (e.g. if
> > someone else commits a change to a file, then I do a 'make', then I
> > update my WC to pull in their change - I want the changed file to
> > have the time of my update, not the time of their commit or the time
> > they changed the file, or else 'make' won't know to rebuild targets
> > that depended on the changed file...).
>
> Hmmm. I think you've got this scenario a little backwards. If you make
> changes to a source file, and commit it; then someone else makes
> changes elsewhere (changes that don't interfere with yours) and commits,
> *that* version of the file is the "correct" (newer) one - not the one in
> your local WC.
>
> When you svn up, if someone has committed changes to a file, that file
> should have a newer timestamp either way - and if the changes from
> someone else's change conflict with changes you've made since your
> commit, the timestamp on your file will be newer still once you've
> resolved that.
I don't think I've got the scenario backwards, but I probably haven't
explained it well - fortunately others on the list have explained my point
better than I did! The gist is that, when the update happens, files
modified by the update must be marked with a timestamp later than the most
recent 'make' that I did, or else things might not get rebuilt that
should...
> Assuming, of course, that everyone's system clocks are in some state
> resembling synchronized. <g>
Of course, this is another good point - but when files get marked with the
time-of-last-update, at least you're only dealing with your the clock on
your own machine!
Patrick
--
The easy way to type accents in Windows: http://www.frkeys.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Issues
Posted by Tom Rawson <tr...@clayst.com>.
On 29 Nov 2004 Kris Deugau wrote:
> When you svn up, if someone has committed changes to a file, that file
> should have a newer timestamp either way - and if the changes from
> someone else's change conflict with changes you've made since your
> commit, the timestamp on your file will be newer still once you've
> resolved that.
I think you're right if you're talking about two people working on the
same file. I think Patrick was talking about this case:
I check out a file at 9:00
At 9:15 someone else modifies it
At 9:20 they commit the mod
At 9:30 I do a build
At 9:45 I do an svn up
I do another build
At this point if the modified file has a 9:45 timestamp (time of the
update) my make will notice it. If it is 9:15 (time of modification)
or 9:20 (time of commit) my make will not notice it. In this scenario
you want to know when the changed version "arrived" on the local
machine, not when it was changed.
--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Issues
Posted by Kris Deugau <kd...@vianet.ca>.
Patrick Smears wrote:
> The reason for the default behaviour is that any other behaviour
> tends to confuse utilities like 'make' that depend on timestamps on
> files to determine which file has been changed most recently (e.g. if
> someone else commits a change to a file, then I do a 'make', then I
> update my WC to pull in their change - I want the changed file to
> have the time of my update, not the time of their commit or the time
> they changed the file, or else 'make' won't know to rebuild targets
> that depended on the changed file...).
Hmmm. I think you've got this scenario a little backwards. If you make
changes to a source file, and commit it; then someone else makes
changes elsewhere (changes that don't interfere with yours) and commits,
*that* version of the file is the "correct" (newer) one - not the one in
your local WC.
When you svn up, if someone has committed changes to a file, that file
should have a newer timestamp either way - and if the changes from
someone else's change conflict with changes you've made since your
commit, the timestamp on your file will be newer still once you've
resolved that.
Assuming, of course, that everyone's system clocks are in some state
resembling synchronized. <g>
-kgd
--
Get your mouse off of there! You don't know where that email has been!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timestamp Issues
Posted by Patrick Smears <pa...@ensoft.co.uk>.
On Mon, 29 Nov 2004 trlists@clayst.com wrote:
> I'm confused about timestamps ... it appears from the following
> sentence:
>
> Normally your working copy files have timestamps that reflect the
> last time they were touched by any process, whether that be your
> own editor or by some svn subcommand.
>
> that svn might be setting timestamps on checkout to the time of
> checkout. Is that right?
Yes, that is right.
> I have two branch directories that appear to reflect this, or perhaps to
> reflect the time the directory was renamed.
>
> What I want is for the file system timestamp to reflect the time I
> changed the file with the editor, not the time it was checked in or
> out, or when the directory it's in was renamed. In other words, when I
> check out a file I want it to have the same filesystem timestamp it had
> when I committed that revision. Can I do this with Subversion?
No, that is not currently possible with just subversion (although it's
possible using, for example, scripts that make use of properties to store
the relevant times).
> I would have expected it to be the default, yet the branch directories I
> created seem to suggest otherwise.
The reason for the default behaviour is that any other behaviour tends to
confuse utilities like 'make' that depend on timestamps on files to
determine which file has been changed most recently (e.g. if someone else
commits a change to a file, then I do a 'make', then I update my WC to
pull in their change - I want the changed file to have the time of my
update, not the time of their commit or the time they changed the file, or
else 'make' won't know to rebuild targets that depended on the changed
file...). Since 'make'-like build systems are a very common use case for
Subversion, this is what the developers have implemented.
Patrick
--
The easy way to type accents in Windows: http://www.frkeys.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org