On Thu, Dec 12, 2013 at 2:39 PM, Eric S. Raymond <esr@xxxxxxxxxxx> 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? curious, m -- martin.langhoff@xxxxxxxxx - 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html