Re: Timestamp Frustrations

On 3 Jun 2005 Ben Collins-Sussman wrote:

> 'svn merge', on the other hand, is just shortcut for making local
> edits. It's no different than opening files in your editor and
> tweaking them. And in that case, you definitely don't want the
> timestamps reset. At a minimum, it would make 'svn status' quite
> slow at detecting edited files. It would be a bit unnatural.

Well OK, then maybe I don't understand merge. I gather I would be far
from the first :-).

I have two main branches of development:

        project/live
        project/dev

Each one has a couple of subdirectories below it. I keep working
copies of both. Sometimes I make bug fixes to the live/ working copy;
these I usually commit and publish right away. Most changes are in the
dev/ working copy, and I don't commit these very often.

The last time live/ was copied to dev/ was r3. I recently finished a
bunch of changes to dev/ and was ready to make them live. I committed
them from the dev/ working copy. Then from the live/ working copy I
did the svn log --top-on-copy to discover that r3 was what I wanted.
Then I did this, also from the live/ working copy:

        svn update
        svn merge -r 3:HEAD file:///h:/svnrepos/project/dev/
        [resolved conflicts]
        svn commit -m "Merge XXX modifications into live branch"

Is this correct? I took it from the "Merging a Whole Branch to
Another" section of the book.

For 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.

--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org