Re: Ambiguous commit message in cvs-1.12

[Derek Robert Price]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark D. Baushke wrote:

>Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>It seems that CVS-1.12 has changed smoe of its messages.
>>Such changes are very inconvenient in and of themselves for
front-ends like
>>PCL-CVS, since you have to update the front-end to correctly parse
the new
>>messages, but one of those changes is even worse because it makes
the result
>>ambiguous.  Here is a sample session that shows the problem:
>>
>>   $ cvs commit -m"test"
>>   cvs commit: Examining A
>>   cvs commit: Examining A/B1
>>   cvs commit: Examining A/B2
>>   /cvsroot/test/A/B1/foo,v  <--  foo
>>   new revision: 1.6; previous revision: 1.5
>>   /cvsroot/test/A/B2/bar,v  <--  bar
>>   new revision: 1.3; previous revision: 1.2
>>   $
>>
>>Apparently two files were commited: A/B1/foo and A/B2/bar, but it's
pretty
>>difficult to figure it out, especially given the fact that a
`modules' file
>>might have mapped /cvsroot/test/A/B1 to A and /cvsroot/test/A/B2 to
A/B1.
>>
>>The old format included a line like "Checking in A/B1/foo;" which
resolved
>>those ambiguities.
>>
>>Ideally (from the point of view of PCL-CVS) the change should be
reverted,
>>but at the very least it should be fixed to include the necessary
>>extra info.
>>One obvious possibility is to replace the "<-- foo" with "<-- A/B1/foo".
>
>
>So, which alternative do you want #a or #b?
>Untested patches for both follow my .signature.
>In both cases, the sanity.sh would require a fair
>amount of work to put in place.


Definately #b.  I found the original commit output extremely
cluttered, redundant, annoying, potentially confusing, and definitely
unnecessary, which is why I removed it in the first place.

Stefan, my apologies for removing the path information by accident and
thanks for the report.  I do understand your frustration about output
changing between releases, but you *are* referring to the feature
releases.  We discussed this a few months back on this list and came
to the conclusion that we would freeze output in the stable releases
as much as possible for programs which parse it but that freezing the
output on feature is much too restrictive.  1.12.x is getting popular
now so it's probably about time to bless it as stable anyhow.  Mark
and I were recently discussing the features we still want to see
before we do and had quite a list, but I may bless it soon anyhow and
relegate the remaining features to the next feature branch in order to
avoid these sorts of problems.

Stable branches are currently lasting on the order of years, so this
doesn't seem too bad a compromise to me.

If you still think this is a problem, it might be time to start
discussing libifying a nice C API for most of the CVS functionality
again, but I don't know anyone with the interest, necessary skills,
and the time to do the work right now.

Cheers,

Derek

- --
                *8^)

Email: derek@ximbiot.com

Get CVS support at <http://ximbiot.com>!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBOHgfLD1OTBfyMaQRAujRAKDkLhHy3Ovl6brPh2Xzib/BOph63ACfYue8
WVppQCqMkP/QVrZAHhxkts4=
=8zKC
-----END PGP SIGNATURE-----