(below...)
Julian Foad wrote:
> Tim Hill wrote:
>
>> 25 years of software development and driving s/w teams, mostly
>> system-level (OS, tools etc.). Have used SCC from SCCS, RCS, PVCS,
>> VSS (yuck), versions of Perforce and SVN.
>
>
> That's about twice my experience in all respects, so I'm _very_ glad
> to have your help.
>
>>> [you could store the bug number in a revision property]
>>
>>
>> I agree -- but the issue is that having created this formal data svn
>> doesn't really allow me to do much with it, programmatically speaking.
>
>
> Hmm ... yes.
>
>> But, really, is creating a tag, with all the branching etc needed, as
>> easy as this:
>>
>> svn commit foo.c --label "DEFECT-FIX:1234"
>
>
> Well, it requires two separate svn commands but it's even easier than
> that if you write a script/macro/shell-function to help:
>
> svn-commit-fix 1234 foo.c
>
> where svn-commit-fix is
> [[[
> #!/bin/sh
> REPOS=http://...
> FIX=$1
> shift
> svn commit "$@" &&
> svn copy $REPOS/trunk $REPOS/tags/DEFECT-FIX-$FIX
> ]]]
>
>
> OK, so some things ought to be built-in, and using external scripts
> and environment variables is not ideal, but I'm trying to concentrate
> on the important facets of the functionality and not worry about the
> command-line syntax to invoke it yet. We can easily add some built-in
> syntax if we think it's important.
>
> More important is that that method results in two commits. That is a
> bigger deal, perhaps indicating that it isn't doing conceptually what
> you want. In your example, the label was to be applied at the same
> time as the commit, but in practice this would only sometimes be the
> case. At other times, the user would apply the label later, so we
> shouldn't be thinking about how to combine the two commits into one,
> but we do need to think about whether the action of labelling should
> be a versioned event.
>
> Do you have any views yet on whether you would want revision-alias
> labels to be version-controlled, or on what the significant
> implications would be if they were or weren't?
>
>
>> ok, what I'm really getting at is that labels should be able to act
>> as a *function* within a command-line; the return value of the label
>> is its rev#, and this return value can be used *within* an svn
>> command wherever a rev# is expected. Tags can *represent* a rev#, but
>> this implied information can only be recovered in certain commands
>> and only implicitly.
>
>
> Well, that's really just saying that what we mean by a "label" is an
> alias for a revision number, on which I think we are roughly in
> agreement. Unless you mean that it should be a more general function
> than a simple 1-to-1 mapping?
>
>
>> You mention the use of revision properties, which would indeed be a
>> prefect way to handle my scenario EXCEPT that there is no way to feed
>> the value of such a property back into an svn command. IMHO svn is
>> crying out for a way to access properties within the command line. In
>> fact, providing such a feature would in fact provide a perfectly
>> valid label mechanism virtually for free, as well as any number of
>> other useful enhancements.
>
>
> That's an interesting idea. Would you care to start a separate mail
> thread about it?
>
>
>> ok, lets' see where I think we are...
>>
>> 1. I think we agree that there might be a case for some enhancements
>> to relative revision numbers to handle the PRIOR or -1 case.
>
>
> Yes.
>
>> 2. I'm not clear on your position wrt how the rev# of the defect
>> check-in is tracked. At one point I think you're arguing that, yes,
>> you *should* indeed create a tag for each such check-in.
>
>
> What I was really saying is that if you want to refer to them by name
> rather than number, which is your basic premise, then yes, creating a
> tag is the closest you can get to your ideal in basic command-line
> usage at present.
>
>> otoh you also mention the use of revision properties
>
>
> What I was thinking there is that if you, as administrator, currently
> want to set up a system that links Subversion to your bug tracker and
> provides the easiest possible command-line experience for your users,
> the best way is probably by writing scripts that store and use the bug
> number in a revision property.
>
>> typically hundreds/thousands of defects in a medium project. Is the
>> tool *really* up to managing all those tags? Are users/admins?
>
>
> Another good point. No, not when they all go into one directory. A
> thousand should be fine but gets slow on BerkeleyDB repositories, and
> some large projects have hundreds of thousands of issues reported.
> Issue #2067 ("Perf issues with BDB and directories with a large number
> of items") is a major factor on BDB, but it's probably not the only
> problem that would make large lists unmanageable. Of course, it might
> not be much easier to ensure that a dedicated list of labels remains
> manageable.
>
>
>
> This is what I think we should do next:
>
> + Consider various avenues that cropped up that might be useful
> regardless of labelling, such as revision-number arithmetic (issue
> #1213) and substitution of property values into a command. We should
> file issues for these as and when they are moderately well thought out.
>
> + Write a detailed proposal for revision-alias labels that would cover
> this simple use case, and discuss it.
>
> + Consider a more complex use case like the following: Each bug fix
> to be tracked consists of a series of non-consecutive commits. If it
> is known in advance that the fix will be complex, then that work is
> done on a branch, and the result is afterwards merged to the trunk,
> but often a commit is made to the trunk that aims to fix the bug, but
> is then seen to be incomplete and one or more follow-ups are made,
> with other unrelated commits happening in between them. We need to
> determine whether and how "labels" should track this situation.
I agree with this. I'm going to go off-line for a few days and work this
up, and will then re-post here.
--Tim
>
> - Julian
>
Received on Tue Jun 7 01:19:46 2005