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

RE: Is there really no way to keep the file modification time intact?

From: John Gwinner <jgwinner_at_dazsi.com>
Date: 2007-03-07 01:03:18 CET

(Thanks Ryan for the clarification on times).

> > Erik meant: add your email address to the cc list of the bug (not of
> > this email discussion).
> Yup. You can find the bug at
> http://subversion.tigris.org/issues/show_bug.cgi?id=1256

Right, I'd done that when I posted originally.

> When I'm looking
> for the amount of interest in an issue, I do look for signs of
> interest.

Well, I may be putting myself in harms way, o.O but I'd venture to say
that anyone thinking of migrating from SourceSafe will expect the check
in time to be file modification time.

They may or may not post on this list.

For PL/SQL packages, i.e. Oracle's JDeveloper, I'm not sure the concept
applies, although there is certainly a modification time in the package.
We would have the same issue here, developers won't check in anything
until the PM tells them to, then we get it all in a dump, possibly
overwriting older checkins.

So to work through a scenario:

Developer Fred and Bob start work on a project. They both save files on
12/24 and go celebrate Christmas. Bob gets a bug reported and fixes it
directly in Production.

Bob checks in all his files on 1/2 2007. He leaves the project.

Fred is told by his Project Manager to make sure everything is checked
in on 3/6 2007. He checks in all of his files from a different instance
(Development), effective modification date of 12/24. His changes
overwrite Bob's newer files.

So we reverted, right?

       == John ==

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 7 01:02:31 2007

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.