On 2/24/2006 1:03 PM, Gale, David wrote:
> Ryan Schmidt wrote:
>> On Feb 24, 2006, at 18:11, robert@infotility.com wrote:
>>
>>> Since we know already that symbolic aliases are useful
>>> (HEAD, BASE, etc) why not set up a mechanism to allow
>>> users to make new ones?
>>>
>>> Various correspondents have suggested workarounds or
>>> hacks of various kinds. Thanks guys, but if there's
>>> evidence that there is widespread desire for this feature
>>> (namely that it has been solved multiple times by
>>> multiple persons) why not just build it into the standard release?
>>
>>
>> I for one just don't understand yet what functionality is being
>> gained.
>>
>>
>> Given a project named $P and a repository whose root is $R, and a
>> standard trunk/branches/tags structure in the project, and a tag
>> named $T,
>>
>>
>> Subversion currently has:
>>
>> To create a new tag:
>>
>> svn cp $R/$P/{trunk,tags/$T} -m "Creating tag $T"
>>
>> To replace an existing tag:
>>
>> svn rm $R/$P/tags/$T -m "Removing tag $T"
>> svn cp $R/$P/{trunk,tags/$T} -m "Recreating tag $T"
>>
>> To check out the tag:
>>
>> svn co $R/$P/tags/$T
>>
>> To get a log of the tag:
>>
>> svn log $R/$P/tags/$T
>>
>>
>> What's being proposed seems to be:
>>
>> To create a new tag:
>>
>> svn alias [-r HEAD] $T $R/$P/trunk
>>
>> To replace an existing tag:
>>
>> svn alias -force [-r HEAD] $T $R/$P/trunk
>>
>> To check out the tag:
>>
>> svn co -r $T $R/$P/trunk
>>
>> To get a log of the tag:
>>
>> svn log -r $T:0 $R/$P/trunk
>>
>>
>> Is it just this alternate syntax that's desired, or is there some
>> additional functionality that's gained over Subversion's existing
>> tagging method that I'm just not seeing at the moment?
>
> I'm not viewing it as an alternate syntax for tags (though I could see
> it being used as a sort of "tags lite" by those who don't like the way
> subversion does tags, I think that'd be silly, as you lose a lot of
> power by doing so). Currently, there are three ways of referencing
> revisions in the repository--by specific number, time, or the HEAD
> keyword (the other keywords don't apply to the repository, just working
> copies). So, to look back at a certain revision, you either need to dig
> through the logs to find its number, or try to remember what day it was
> that you're interested in. Giving the users the ability to create
> useful, human-readable (and rememberable) names for specific revisions
> would be an enhancement.
>
> The first use case that occurs to me is for merge tracking. Say you've
> got a typical layout:
>
> -trunk/
> -tags/
> -branches/
> |-branch1/
> |-branch2/
> |...
>
> 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?
Duncan Murdoch
---------------------------------------------------------------------
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:03:30 2006