[openfabrics-ewg] drop mthca from svn?

[Michael S. Tsirkin]

Quoting r. Bryan O'Sullivan <bos at pathscale.com>:
> As far as I can tell, you took a git snapshot at some point, then
> started copying some select files from SVN in there, hacked on various
> bits and pieces, did merges with bits from upstream, and simultaneously
> developed both backport and fix patches.

No, you got that wrong.
That's not what we did - we took a git snapshot and added out of tree
modules from svn - only file additions.  Then we periodically merge upstream
code from linus as it is developed. Changes in upstream modules against Linus
tree are kept as patches.

This was described by Tziporet in her presentation.

What I think is missing is a tag marking the last revision from Linus
that we merged. After the next RC goes out we'll merge from Linus
one last time and then tag it properly.

> The result is a hodgepodge of
> code, the history and state of which is tricky to follow.

Try qgit or another history visualization tool.

> If you were to maintain all of your changes as a series of patches
> against a (preferably well-known, such as "a recent RC") revision of a
> pristine kernel repository, this would be much easier to track and
> manipulate.

But out of tree modules won't have any history then.

> The nice thing about a series of patches is that it's easy to rebase and
> portable across a variety of revision control systems.  You can use
> quilt, Mercurial Queues, StGit, or just plain patch depending on your
> particular religion.

My particular religion does not seem to involve revision control systems
in any way :) Git is used in ofed because that's what Roland and Linus
use, to make it easy to merge from upstream. And it *is* trivial -
so far all I ever had to do was git pull.

It seems that using mercurial might be hard for you
to follow ofed tree, but that's probably deficiency in git to mercurial
gateway. Try looking at ofed tree directly and not through that.

In any case, patches is a fine thing for small changes.  But you loose *all*
history with them.  Pathscale "fix" patch is one example where it is impossible
to even understand what got changed and why.

While following history of merges from multiple trees might be hard it is better
than not having any.  

-- 
MST