Fabian Groffen posted on Thu, 02 Jun 2011 11:13:38 +0200 as excerpted: > Obviously, all history is lost. VCSs other than CVS might keep history > across moves here (svn, git, hg...), hence a "follow" could perhaps find > renames. Question is if this can be detected in such a way that a > useful ChangeLog can be generated. Will version bumps that are almost > identical copies, that show up as copies/renames cause issues here?
Git, which has been described as a content tracker that happens to have a DVCS of the same name built around it, definitely follows moves/renames without losing history. It even has an adjustable percent-change threshold at which a similar file is detected as a move/rename, for purposes of git-log and statistics generation. The problem with autogeneration based on git log would then come down to the impedance miss-match between git as a content tracker and a file-based changelog. For those with access to the full git repo and log, it isn't normally a problem since the content isn't lost, you just switch your git log filtering to include both locations instead of just one. (And false- positives aren't generally a problem either in that case, the human filter picks up on it pretty fast and rejects it /as/ a false positive, and the the git log filtering simply doesn't get changed.) This of course is yet another factor in favor of allowing full git-pull access to all, the whole auto-generation thing becomes moot. If full git-pull access is not allowed for all, however, or if the rsync sync options are retained as they likely will be in any case, then generated changelogs remains a valid consideration. Perhaps the easiest approach in that case would be to simply take the limitation at face value, accepting that generated changelogs apply to only the current package name, and to lookup what happened before a move, one either does the full git checkout (if it's a public option) and looks there, or checks the gitweb, etc, status. As for dealing with the existing history and changelogs, either the conversion scripts can take what they can get out of the CVS logs and settle for that, or the existing changelogs could be committed, then deleted and that committed, so anyone wanting to see the existing history at the time of the conversion could simply check the changelog as it was initially committed and then deleted. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
