"Scott L. Burson" <Scott@solidcore.com> writes:
> > "Merge tracking" is a desirable feature, absolutely. The book even
> > mentions it. But you've just barely described the tip of the iceberg.
> > The system should be tracking this stuff internally and actually
> > understanding it, not just appending auto-generated text to log messages
> > for humans to read. We'd like to solve the real problem, not just make
> > the symptom a bit less painful. :-)
>
> A worthy goal, but while you're working toward it, a bit of auto-generated
> text would make things quite a bit less painful. As things stand, this
> information can be quite difficult to infer after the fact.
>
> I don't know how hard this auto-logging would be to implement, but
> if it isn't hard, I beg you to do it, even if only as an interim measure.
Well, you can add the merge command to the log message yourself
(that's what I usually do).
It's not good for us to go making ad-hoc standards, in the hopes that
they won't get in our way too much in the future, or not be obsoleted
by a more complete solution. A moment of convenience, a lifetime of
regret...
If you really try to flesh out your feature suggestion, "add an
annotation to the working copy that receives the merge, giving the two
source URLs and revision numbers; this annotation would be
automatically added to the log message at the next commit", you'll
quickly run into all sorts of complexities and problems. Now we'd be
committing a log message that's different from what the user writes
themselves. I'm sure you can see the possibilities for lossage here.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 15 00:31:43 2004