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

RE: [DESIGN] Aliases? (Was: RE: Re: I, too, miss tags.)

From: Gale, David <David.Gale_at_Hypertherm.com>
Date: 2006-02-24 20:16:25 CET

Duncan Murdoch wrote:
> On 2/24/2006 1:03 PM, Gale, David wrote:
>> Currently, the recommended practice is to carefully note what
>> revisions are being merged into the trunk in the log file of the
>> merge, and then when you next merge, dig through the log looking for
>> the last merge comment.
>>
(http://svnbook.red-bean.com/nightly/en/svn.branchmerge.copychanges.html
>> ) If, however, you were able to create an alias for the last merged
>> revision, you could do the following:
>> $ svn merge -r BRANCH1_LAST_MERGE:HEAD <repos>/branch1
>> <verify and commit>
>> $ svn alias -force -r HEAD BRANCH1_LAST_MERGED
>> As long as everyone who does merges updates the alias as well, you
>> don't need to dig through any logs to determine which revision to
>> start the merge from.
>
> Would that work? HEAD could change during that <verify and commit>
> step, which in my experience sometimes takes several hours. You'd
> want to record what HEAD was at the time of the merge, and use that
> rev number instead of HEAD in the last step.
>
> If there were a way to make that automatic (which would require better
> merge support), the alias would be more useful. But with better merge
> support maybe the example would go away?

Ok, replace the alias command with:
$ svn alias -force -r <version merged in> BRANCH1_LAST_MERGED

Currently, you need to note down the last version you've merged in so
that you can add that to the log message, so noting it for this purpose
isn't any new work. And you still wouldn't need to dig through the log
messages to figure out the starting point for the next merge.

And yes, better merge support would make this example no longer valid.
Of course, merge tracking has been one of subversion's most requested
and longest outstanding issues, and involves more than this feature
would fix.

One possible way to automate this would be to write a wrapper around svn
merge which stores the revision in a temporary spot (perhaps an
environment variable, a file in /tmp, or even a different alias in the
repository), and then have a script that, after the verification step,
issues the commit and updates the tracking alias to the value stored in
the temporary location.

-David

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 24 20:18:51 2006

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