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

Re: Merge Help

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-06-04 18:21:48 CEST

On Jun 4, 2005, at 7:03 AM, trlists@clayst.com wrote:

> Re the earlier discussion on timestamps, what I really want here is
> for
> the files in the live/ wc to have the same timestamps as they had in
> the dev/ wc -- i.e. the last time the file was actually modified
> (putting aside any mods to resolve conflicts). So unless I'm using
> merge incorrectly, I think this is a case where you would want
> merge to
> preserve the timestamps, if they were being preserved at all.

I understand your point, it makes sense. In other words, if
subversion were versioning timestamps/owner/permission metadata, then
that stuff would be preserved when porting changes, just the way file
contents are preserved.

Unfortunately, subversion doesn't version filesystem metadata. The
current design is such that when you import files into the subversion
repository, you're moving them to a new filesystem (the repository),
and it then generates its *own* filesystem metadata: last-commit-
time, last-author, last-changed-rev, filesize. This is all the stuff
that 'svn ls -v URL' shows. All of the original metadata is lost.

The working copy is just a disposable shadow of the 'real'
filesystem, so you need to switch paradigms here. Instead of using
OS timestamps to copy stuff between working copies, use the *real*
filesystem to do the syncing -- that is, the repository. 'svn
commit' when you need to save your work, 'svn update' on another box
to get the changes in progress. The svn repository is capable of
doing everything that your timestamp-syncing script is already
doing; you just need to embrace it as the center of your workflow now.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jun 4 18:24:26 2005

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.