Hi Mauro, You have put a lot of effort in tracking down this issue.
> Unfortunately, I wasn't able to understand what the discriminant factors Yes, there doesn't seem to be a visible pattern to the error. > - files in 4 different branches were involed How is it possible to do a single commit against multiple branches in CVS? Is that what you did? > I don't know in which order the changes were committed, but since I'm > using an IDE that lists the changes in alphabetical order, I would > expect that changes were submitted in the same order I used to name > branches, paths and files. Moreover, it might be that changes in B1 and > B2 were sent with an only cvs client invocation, while changes in B3 and > B4 with another one. It seems that perhaps you committed multiple times, once per branch, although it may have appread to all gone through at the same time because the IDE was issuing these commits. If so, it may be easier to identify the problem if you issue the commits on your own on the command-line. > So, my question is: why don't changing the approach and do the > consolidation on the daemon side? That was my original idea. Doug provided the current implementation, it seemed to work at the time, and it stuck. I think I'll remove this cvs_consolidate_messages implementation. > This approach may be used for repositories other than CVS too: it could I don't know of any other such archaic repositories worth supporting :) > make sense to have this approach even to group together two different > SVN changesets sharing the same comment log/bug#/committer, if the > second one is issued soon after the first one (maybe the committer > forgot to commit one file together with the previous changeset?). The revision numbers would be different, but given the same logs they may be worth consolidating. I know I forgot to commit files before and lazily pressed the up arrow on the command-line and used the exact same log message. > What do you think about this? I think this idea would work.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
