Merge Help

[tr...@clayst.com]

I am reposting this from another thread because it got no response, and 
I'd be interested in some feedback as to whether this is the correct 
use of merge ...  

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

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.  

--
Tom




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

Re: Merge Help

[Ben Collins-Sussman <su...@collab.net>]

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