Robin Rosenberg wrote: > The idea is nice, but the downside of this patch is that I (and presumably > others) have to rewrite the scripts to invoke cvsps explicitly now. This patch did _not_ change how we invoke cvsps at all. It did change that we now ignore the very recent commits (and pick them up in the next run), unless you pass -a. > The fix > should really be in cvsps, not git-cvsimport (which is the reason I haven't > fixed this). Running a full cvsps takes two hours and consumes more than a > gigabyte of memory for me, which makes it impossible to run on all but one > machine, wheras the incremental import runs in less than five minutes on any > machine. Many things would need fixing in cvsps. This aspect [that commits we do not know if recent activty belongs to a finished commit or a commit that is still happening], is not cvsps' fault. It is due to the lack of atomicity in CVS, combined with its rather bad network protocol. > Add to that the risk that the buggy nature of cvsps probably increases the > risk of errors, so please make the old behaviour the default (import all, > retain cvsps cache) and make the changed behaviour the result of an explicit > switch. What seems to concern you is the "retain cvsps cache" -- which we do. I did comment later in the thread that we should consider rebuilding the cvsps cache. The reason for that is that I am seeing LESS breakage than maintaining the cache. Significantly less. As you say, however, it is a major change, so I'm still evaluating options. cheers martin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html