[EMAIL PROTECTED] (Ludovic Courtès) writes: > Option (1) requires a tool like `cscvs' and I suspect that this is not > trivial to achieve (I've never tried it, though). Also, it's maybe not > very useful since you could as well access the history of your project > using CVS anyway.
Something like cscvs tries to detect "logical changesets" in the CVS repository, and commit each one to arch as a separate arch revision; if it works, it is a nice thing, but because it depends on heuristics (CVS simply doesn't keep enough information to do it properly) it won't work well unless your CVS repository follows certain conventions. In particular, I think cscvs uses comparison of log entries and dates so that commits done with "cvs commit -mMSG lots of files..." will be detectable as a single "changeset" (because they all have an identical log msg and a very close commit date). Projects where everybody commits each file separately with different log messages (like emacs :-( ) are pretty much hopeless. In cases where cscvs _doesn't_ work well, I'm not sure the resulting arch repository (which would end up with something like each change to each file having its own arch revision) would be very usable... Maybe it's better and simpler to just check in each real release / daily-snapshot / whatever as an arch revision, and call that close enough (if you don't do daily snapshots, you could just iterate though the CVS repository and check out a snapshot at 4am of every date...). -Miles -- Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come. --Nietzsche _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
