Re: [Gnu-arch-users] cscvs - a couple of bugs

[Paul Mundt]

On Sun, Mar 21, 2004 at 02:42:46AM +1100, Robert Collins wrote:
> Secondly, and more seriously, the changeset identification algorithm is
> broken. The date based sort is (unfortunately) flawed - and this is only
> visible in my branch. Your branch, which uses the tree-lint -t magic to
> add files will appear to work, but will actually generate incorrect
> changesets - for instance placing a change some hundreds of revisions
> after 1.1.1 as changeset 1 in cscvs. Mine will bork on commit, as the
> files are not added (due to them being a change, not a new-on-branch).
> 
I've just run into this as well, this only appears to happen for non-MAIN
branches (at least for me). cset 1 ends up looking rather confused.. in
my case, I can see a small handful of changes that happened years later
being tossed in with cset 1, which is clearly wrong. This happens for me
both on your branch and on Charles' (at least as far as a cscvs log goes).

This also leaves certain things broken further along as well, since I'm also
seeing revisions added in cset 1 that weren't actually added until much
later, but then also being modified in subsequent changesets. This is not so
much an issue by itself, but cscvs seems to be selective about what it wants
to keep intact, and what it doesn't. For example, I have some ChangeLogs that
are showing up in cset1 that weren't added till much later, but the point where
they were actually added still shows up, so skipping over cset1 in this case
would be fine. However, I also have some div64 changes that were added later,
and subsequently modified after that, but these only ever show up in cset 1,
so skipping over those isn't particularly feasible, unless I recreate it by
hand.

Any suggestions? I can provide log output and a link to the CVSROOT tarball
if anyone wants to take a look at it.

pgpFKrHJ7A86B.pgp
Description: PGP signature