On Thu, Dec 12, 2013 at 2:39 PM, Eric S. Raymond <e...@thyrsus.com> wrote:
> Yikes!  That is a much stricter stability criterion than I thought you
> were specifying.

:-) -- cvsps's approach is: if you have a cache, you can remember the
lies you told earlier.

It is impossible to be stable purely from the source data in the face
of these issues.

CVS is truly a PoS.

> I think it would handle 1a in a stable way

that is pretty important. Files added on a branch not affecting HEAD
and earlier branch checkout matters.

> What I think this means is that cvs-fast-export is stable if you are
> using a server/client combination that generates commitids (that is,
> GNU CVS of any version newer than 1.12 of 2004, or CVS-NT). It is
> *not* necessary for stability that the entire history have them.
> Here's how the logic works out:
> 1. Commits grouped by commitid are stable - nothing in CVS ever rewrites
> those or assigns a duplicate.
> 2. No file change made with a commitid can destabilize a commit guess
> made without them, because the similarity checker never tries to put both
> kinds in a single changeset.
> Can you detect any flaw in this?

If someone creates a nonsensical tag or branch point, tagging files
from different commits, how do you handle it?

 - without commit ids, does it affect your guesses?

 - regardless of commit ids, do you synthesize an artificial commit?
How do you define parenthood for that artificial commit?


 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to