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
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