On Mar 5, 2005, at 7:20 PM, Peter McNab wrote:
> Max Bowsher wrote:
>
>> Branko Čibej wrote:
>>
>>> Max Bowsher wrote:
>>>
>>>> fitz@tigris.org wrote:
>>>>
>>>>> Author: fitz
>>>>> Date: Fri Mar 4 17:10:40 2005
>>>>> New Revision: 13266
>>>>>
>>>>> Modified:
>>>>> branches/locking/subversion/libsvn_client/locking_commands.c
>>>>> Log:
>>>>> Fix stupid crasher bug (committed by me) when attempting to lock
>>>>> files
>>>>> that are in subdirectories.
>>>>>
>>>>> * /trunk/subversion/subversion/libsvn_client/locking_commands.c
>>>>> (open_lock_targets): Index into the same array that you're
>>>>> iterating
>>>>> over. Duh.
>>>>
>>>>
>>>>
>>>> Hi.
>>>>
>>>> In several recent commits you've been using a weird form of filename
>>>> in log messages.
>>>> In this case, it is particularly incorrect, since it says "trunk"
>>>> but
>>>> was actually a branch commit.
>>>
>>>
>>> This is getting worse and worse. Soon we'll be so far along that not
>>> a
>>> single commit will be made with a well-formed log message.
>>>
>>> We've relied on self-discipline to keep the format consistent for
>>> years
>>> now, but it seems that some of the new (and old!) committers are
>>> slipping their leash. So. Is it time to write that hook that rejects
>>> commits with log messages that don't conform to the documented
>>> format?
>>
>>
>> I don't think our format is sufficiently rigorously defined for that
>> to be feasible.
>>
>> I think that the problem is still sufficiently small that
>> self-discipline combined with pointing out of mistakes can continue
>> to work.
>>
>> Max.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: dev-help@subversion.tigris.org
>>
>>
> Hi List
>
> Sitting back as a relative new indirect user of SVN via TortoiseSVN I
> have been monitoring the user and dev lists to get some feel for the
> issues that may crop up for me as as single developer.
> One which stands out is the inability to rely on the log message to
> contain anything meaningful and even worse is for it to be incorrect,
> because it relies on human endeavor.
The problem we're discussing has nothing to do with whether or not log
messages are "reliable". This particular thread is about people
conforming to formatting standards. We're arguing about syntax, not
content.
> I am quite surprised the log message doesn't automatically contain
> something along the lines of the command line parameters and SVN
> revision number itself, that resulted in the generation of the log
> message, ahead of the user's comments, if any. For instance, when
> committing a merge it's far too easy to enter the wrong revision
> numbers, either by being +-1 out or be just plain dyslexic with the
> numbers.
> The log entries for tags and branches don't automatically contain the
> revision from which they were generated.
>
> If portions of the log entry was automated it might then be possible
> to programatically warn the user if they attempted to re-merge from
> previously merged revisions or attempt to merge from a point ahead of
> a branch point.
> Revision control via SVN still appears to be very susceptible to the
> influence of human error and ignorance.
> In the hands of an experienced users it is very good but not all of us
> use it sufficiently or frequently enough to remain fully conversant
> with every nuance and so the human errors remain inevitable.
>
Congrats, you've just re-explained one of the main reasons we need to
implement merge-tracking, which is well known and has been discussed
many times. :-)
When svn does learn to track merges automatically, it probably won't be
doing it in the commit log messages, but more likely in the versioned
metadata ("properties"), or perhaps even deeper within the system.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 6 02:35:50 2005