On Sun, Dec 13, 2009 at 01:18:53PM +0100, Eike Hein wrote: > In the broader scheme of things, I'd rather fix a fuck- > up now and then than make contributing harder. I'd say > erring on the side of lower barrier to entry is best. > it's a per-project decision. best for you isn't best for everyone.
> Writing these rules is a major job. > it's not a major job - it's an insane job. for cvs2svn, i had a semi-automated process and still needed about two weeks fulltime to fixup the rules. and back then we had no kdereview and the repo was smaller overall. and the job of really modularizing the monster modules is still open. that's a much broader topic and needs to be brought to core-devel as soon as the release is out. > - You need to handle weird stuff cvs2svn did back then, > like the insane way it created tags and how they were > later manually renamed/moved in /tags > the location where cvs2svn put the tags was just fine, even if somewhat naive for actual use in svn (one could do better with current cvs2svn). but after the git import, that will be irrelevant. i'd even try to get back the original tag names. of course, the conversion step as such is still something to consider. what i'm more concerned about is the fact that cvs2svn simply fucked up branches (and most probably also tags) - files are simply missing. so far it has been suggested that we'd simply drop pre-svn branches, so i didn't investigate a retroactive fixup further. > - kde-common/accounts is insufficient as an account map > because of account names changing between CVS and SVN > or accouns getting deleted, so conversions need to be > examined and gaps filled in > in theory cvs2svn should have already mapped that. obviously some entries were missing or an entire case class was not considered at all. :( _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
