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

Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed

From: Giovanni Bajo <rasky_at_develer.com>
Date: 2005-11-28 13:11:45 CET

Ph. Marek <philipp.marek@bmlv.gv.at> wrote:

> - To save the (modification-) timestamp for each committed file, and
> to restore them.

It's not clear to me whether "svn up -rN" should restore the modification
time of the files at that revision. If so, that would break a common usage
pattern such as:

svn up -r1234 foo.h
make # rebuild only files affected by the foo.h change

which would be IMHO a regression (at least if done by default). Another
broken one would be:

touch foo.h # local modifies
make
svn revert foo.h
make # should always rebuild!

I took some time to search the archive for previous discussions about mtime
versioning. After some reading, the only argument that convinced me is that
of importing external trees. In my mind, it would be "svn import" *only* to
remeber the mtime of the files being imported (at least by default), so that
it can be restored later. I still fail to see what's good in having "svn
commit" records and stores the mtime of each and every file. Off the top of
my head, you will also have to fight endless trouble with timezones, DST,
different time encoding in Windows and UNIX, and whatnot.

If you are going to post an updated design as suggested by Julian, make sure
to have a section with use cases (aka motivating reasons) for this feature.

-- 
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 28 13:29:49 2005

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

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