Em Terça-feira 20 Janeiro 2009, às 16:49:35, Oswald Buddenhagen escreveu: > On Mon, Jan 19, 2009 at 08:52:23PM +0100, Thiago Macieira wrote: > > All of them contain the imported history. > > ok. > not that i understand the need for separate repositories for the > "live" branches in the first place, but whatever. :}
We don't. I was following the structure we set up for Qt (qt/mainline.git, qt/qt-45.git, qt/qt-44.git) But the next day after posting the suggestion, Simon came to me and suggested we actually move away from it. Using one repository for the "live" and official branches should be enough. And it should have the name of the project itself (if you do "git clone $URL/mainline.git", you get a subdir called "mainline"). > anyway, note that the historic (cvs) branches in our svn repo are still > screwed up. that means that either somebody invests time into fixing > cvs2svn and fixes the history retroactively (i have coolo's ok for that, > just no time for it) or that the history is cut (after the ad-hoc fixes > and general reorganizations that happened in svn after the import) (it > would be still possible to make the history available in git via a graft > at some later point). True. Interestingly, GNOME has the same issue too. I've been talking to their lead proponent on switching to Git and he noticed the same kind of failure in their SVN import. My suggestion to him is the same I make here: forget the historic originally- CVS branches in the initial import. None of them are relevant today. We can fix history later in those branches. After all, we have been living with them broken since April 2005 and no one has complained. > btw, does any svn => git tool understand module moves within a bigger > repository or would the history before the last move be lost anyway? > that's not relevant to amarok in case it was never moved, but it > certainly affects a lot of kde in general. None do. I have plans to add this support to svn-all-fast-export, but never came around to doing it. It's very complex, because you can't walk history linearly anymore: the moment that you detect a copy-with-history from outside your repository, you have to go back. When it sees a copy-with-history in SVN, it tries to heuristically determine what was meant: - if it's a copy within the same repository and same branch, it doesn't do anything and lets Git resolve it later (it's a local copy or move) - if it's a copy of the root of a repository and the branch name stays the same, it's SVN reorganisation (i.e., trunk/kdelibs -> trunk/KDE/kdelibs) - if it's a copy of the root of a repository and the branch name changes, it's branching or tagging (SVN has no concept of tags, so it treats both as the same) - if it's a copy across repositories, it's simple copy-with-history but it doesn't do anything about it. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Software Engineer - Nokia, Qt Software Qt Software is hiring - ask me PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
