[Kde-scm-interest] On Amarok Switching to Git

[Thiago Macieira]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20090120/cc642844/attachment.sig