[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: preserve modification date on co?

From: Walt Armour <WaltA_at_concur.com>
Date: 2004-09-09 23:48:04 CEST

> -----Original Message-----
> From: Patrick Smears [mailto:patrick.smears@ensoft.co.uk]
> Sent: Thursday, September 09, 2004 2:27 PM
> To: Walt Armour
> Cc: users@subversion.tigris.org
> Subject: RE: preserve modification date on co?
> On Thu, 9 Sep 2004, Walt Armour wrote:
> > > I'm not sure what you mean about modification time being
> beneficial in
> > > comparing files and directories, though, it seems diff is what you
> > > really want to use, and if the timestamps differ, it still doesn't
> > > matter...
> >
> > I believe this was briefly mentioned in a previous post.
> In situations
> > where a generated file (generation conditional on source file
> > modification times) is also kept in SVN it would be very
> useful to have
> > the file timestamps be the actual modification times to facilitate
> > proper generation in later checkouts.
> I'm not sure it buys you as much as you might want it to...

I don't want it to buy me anything since I don't think we need this
behaviour. I was just explaining it for someone else. :)

> Suppose you've got a file C, which is compiled from files A &
> B. (Maybe C
> is an executable, and A and B are the source files).
> Suppose in my working copy, I edit A, and do a 'make' to
> generate C. Then
> A & C will have times of about now.
> Suppose someone else was working on file B last night, and
> committed some
> changes.
> Now, I update my workspace. If svn preserves modification
> times, then B
> will have a time sometime last night - older than my C, which I just
> recompiled. If I do a 'make', then C will *not* be rebuilt -
> even though B
> has changed. Thus I'm fooled into thinking C is a compiled
> version of my
> source - when in fact it isn't...

Actually, that may not be the case. Since they updated B they should have
rebuilt C (if not then we have a process break and there is nothing SVN can
do about that one). When I update I would get that older B but C should
conflict (it better but to be honest I'm not positive it would given SVN's
handling of binaries and my lack of SVN experience. anyone?). In this case
I will have to rebuild C to clear the conflict and everything will be good.

Of course if SVN merge's executable binaries then all bets are off....

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Sep 9 23:47:35 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.