On Jul 11, 2007, at 17:01, Tom Kielty wrote:
> I am having problems merging a revision from our trunk to a tag.
>
>
>
> When we do a build we create a tag of the trunk. Then a checkout is
> done of the tag. If the build fails, the developer responsible
> makes the fix commits the change to the trunk. They send an e-mail
> to me that says their fix in part of rev 123 for example. I then do
> a merge of trunk revision 123 and my working copy:
>
>
>
> svn merge -c 123 http://svnserver/trunk@123 > merge.txt
>
>
>
> I then replace all the “U “ with the working copy path in the
> merge.txt file.
>
>
>
> Then I do a commit
>
>
>
> svn ci --targets merge.txt -m"Update”
>
>
>
> The reason I use the merge.txt is that during the commit I only
> want the files I specify to be committed. I am seeing some strange
> results and wanted to confirm that my approach is correct?
It should be fine to do it that way. But it should be fine also to
just commit the entire working copy. Subversion will only transmit
the actual differences to the server, so if those specific files are
the only ones that have been changed, then that's all that will be
sent to the server.
Of course, if you do have other unrelated changes in the working copy
that you don't want to commit at the same time, then your approach
may be better.
> Also I am running into the situation where a user has multiple
> revisions for a fix. Is there an easy way to include all rev or a
> range of rev’s in the above example?
That should be easy, e.g.:
svn merge -c 123 http://svnserver/trunk@123 > merge.txt
svn merge -c 125 http://svnserver/trunk@125 >> merge.txt
svn merge -c 130 http://svnserver/trunk@130 >> merge.txt
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jul 12 00:21:57 2007