Migration considerations

[Felipe Contreras]

On Tue, Feb 8, 2011 at 7:01 AM, John Bailey <rekkanoryo at rekkanoryo.org> wrote:
> On 02/07/2011 07:33 PM, Felipe Contreras wrote:
>> I wrote that svn-patch-authors file, and a simple 'git filter-branch' script
>> fixes the authors in no time:
>> https://github.com/felipec/pidgin-git-import/blob/fc-svn-fixes/fix-svn-authors
>
> I thought I mentioned that it was your partial map.  I apologize for not doing
> so.  That said, Richard *did* correctly point that out in the next message in
> the thread.

Good. I was wondering why you didn't notice.

>> There is no advantage from hg's convert whatsoever.
>
> Except the avoidance of a middle-man git repo that isn't strictly necessary.
> I'm willing to trade 30 hours for the simplicity of avoiding yet another tool in
> the process.  It's not like we're active enough that it's going to kill us to
> have a 48-hour freeze on commits and pushes.

The problem is that the conversion scripts are a work in progress, 64
commits so far. And most of time they are changed you have to rebuild
the repo.

I'm aware of that pain, that's why I even profiled 'mtn git_export'
and fixed the bigger bottlenecks, and now it takes about 20min to do
the full conversion.

>> I wrote that file, as you can see in the hg log. We have been collaborating, if
>> you take a closer look a the pidgin-mtn-conv-files repo you would see that I
>> have contributed a lot of work.
>
> Yes, you've contributed some work.  And I thank you for that.  I will gladly
> accept contributions that make our converted history more accurate.
>
>> In git, there are standard tags, such as 'Signed-off-by'. Say, if you apply a
>> patch by me, the s-o-b's would be:
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras at gmail.com>
>> Signed-off-by: John Bailey <rekkanoryo at rekkanoryo.org>
>
> Again, as Richard pointed out, these are not "in" git.  They are
> changelog-inline metadata that the Linux kernel adopted.  Yes, they've caught on
> with other projects.  That doesn't make them a gitism.  We could use these in
> hg, bzr, darcs, mtn, and even in cvs, rcs, and SCCS.  They have merit, but I'd
> rather have seen something like:

See git commit --signoff:
http://www.kernel.org/pub/software/scm/git/docs/git-commit.html

And git format-patch --signoff:
http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html

And git send-email --[no-]signed-off-by-cc --suppress-cc=cc,sob
http://www.kernel.org/pub/software/scm/git/docs/git-send-email.html

It's very much part of git.

> Originated-By: Some Random Idiot <random at idiot.com>
> Approved-By: John Bailey <rekkanoryo at rekkanoryo.org>
> Approved-By: Someone Else <someone at else.org>

Sure, you can add those, but in git only Signed-off-by and Cc have
special meaning.

>> No, you could just use 'git filter-branch' as I do in pidgin-git-import.
>
> That would be perfectly acceptable to me if we were converting to git.  But
> we're not converting to git.  I don't want a third tool in the conversion process.

You are quite fond of providing non-arguments. You say you don't want
a third tool in the conversion process, but you don't have any valid
reason.

>> Now, one of the proposals was to provide both git and hg repos, however, it
>> would be great if you store data that can be easily exported to git.
>>
>>  1) Provide both committer and author. Either with Signed-off-by or some other
>>     method, but you have to provide both somehow.
>>  2) Always provide valid authors. In git, they are in the form "Real Name
>>     <email at box.com>", and the mail part is _mandatory_. If there's no mail
>>     address, <unknown> would make sense.
>
> I agree it would be a nice convenience to provide a git "mirror" of the hg repo.
>  That said, it's not strictly necessary, as there is a way a git user can use an
> hg repo transparently with git, conveniently called git-hg.  At this point I
> don't care whether someone other than me wants to maintain such an "official"
> mirror or if our official stance will be to use git-hg.

Awful. You don't want to use a "third tool" in the conversion process,
which happens rarely, but you want to force that to contributors that
prefer git. Very empathetic of you.

>> Also, remember that the idea was to start a repository from scratch, so, even
>> if the conversion tool is not finished yet, that doesn't matter as it can
>> always be fixed later on.
>
> It was an idea that was discussed.  As I recall, I'm the only one who expressed
> interest in actually doing any of the creation and subrepo joining and whatnot.
>  Unless someone else wants it also, the idea is dead.  That said, I wanted the
> fresh start to happen at 3.0.0, not immediately, so things can't be left
> temporarily and fixed later.  It has to be perfect at the beginning.

Awful. So the idea of having a repository for each project is dead too.

And no conversion is ever perfect. You *will* have issues that are
found after you migrate, and they would have to stay forever in the
history. Or at least until you realize that hg was not a good choice.
I for starters can think of a list of mtn commits that, like svn
commits, didn't have the right patch author, this guideline was
introduced only later, when I pointed that out.

Cheers.

-- 
Felipe Contreras