Re: [gentoo-scm] repoman patch for git support (from drobbins)

[Alec Warner]

On Sat, Nov 15, 2008 at 8:53 PM, Donnie Berkholz <dberkholz@g.o> wrote:
> On 23:07 Sat 15 Nov     , Mike Auty wrote:
>> The idea was to test an as-close-to-the-real-thing version of git
>> portage as possible.  Would repoman commit to the local repository and
>> then push back to the main tree, or would repoman do the push to the
>> main tree directly?
>>
>> I could clone my clone to do local testing, but I thought the idea would
>> be to try out some test/real commits to a large remote copy of the tree,
>> and see how all the patches hold up?
>
> The patch in repoman just commits locally, it does not push. I suppose
> an operation or option could be added that treats that as if it were a
> single combined step, but I definitely do not want that as the only
> choice.
>
> There's still a lot of unresolved questions about the precise repository
> setup and work flow, so simulating it isn't entirely possible yet.
>
> One major problem with repoman+git is that a major feature of git is
> fast commits, but repoman is pretty slow (try a scan in
> x11-base/xorg-server). Anyone got a good idea for how to deal with this?

Change the workflow[1].

Right now you pay the cost of running tree-wide tests every time you
commit.  This incentivizes developers to commit less often (to avoid
paying the tax of tree-wide tests).

In CVS commiting less is a problem:

1. Make Changes to a number of files.
2. Script your commits.
3. Run Script
4....N: Script commits one file at a time.
4.5: A race condition between changes you have commited to CVS versus
uncommited changes occurs when CVS is synced to Osprey.  This race
condition can often cause tree oddness.
5.  All Changes commited.
5.5: All changes synced to Osprey.

I am unsure if repoman category and repoman tree-wide commits avoid
this race condition.

A new scheme would be:

1. Make Changes to a number of files.
2. Category or Treewide Repoman commit.
3. Run taxing tree-wide tests.
4. git commit -a (?)
5. Done!

Tell me if I'm horribly wrong or missing something, it is late here.

-Alec

[1] I fully support server-side tests but I have low expectations for
their implementation or deployment.  Also it stands to reason that
distributed tests scale better in the long run and it is likely that
we could make our local tests run much faster if we dedicated some
developer time to it.  I am sensing a possible SOC project here?

>
> --
> Thanks,
> Donnie
>
> Donnie Berkholz
> Developer, Gentoo Linux
> Blog: http://dberkholz.wordpress.com
>