Am Dienstag, 14. Februar 2012, 14:14:21 schrieb Ruediger Meier:

> On Tuesday 14 February 2012, Adam Spiers wrote:

> > Adrian Schröter (adrian@suse.de) wrote:

> > > Am Montag, 13. Februar 2012, 22:13:54 schrieb Adam Spiers:

> > > > Could it make sense to switch the OBS backend to git?

> > >

> > > There is a stub for that but a lot is missing like event handling

> > > and release counter handling.

> >

> > I see. Would be interested to learn more about what's missing at

> > some point ...

> >

> > > And you can't use git for entire projects

> >

> > Agreed, that would be a bad idea, unless each project tracked its

> > packages via sub-modules.

> >

> > > or even a repo for package repo,

> >

> > This is what I had in mind.

> >

> > > because the size of the tar balls would kill you in default

> > > settings.

> >

> > git-annex would easily solve that problem.

> >

> > > And git sub-projects are just the horror ...

> >

> > Oh, OK :-) Why don't you like them?

> >

> > > > Or at least build a git-obs bridge, in a similar manner to the

> > > > existing git-svn bridge?

> >

> > Of course I'm biased because this is my idea ;-) but I think that

> > git-obs would be a cool step towards a more decentralized model. It

> > would only provide decentralization client-side (i.e. from the

> > perspective of OBS users), but that makes sense to me anyway, since

> > the OBS server is unavoidably centralized. Then it would allow users

> > to visualize package branches with standard tools like gitk, submit

> > requests would map to pull requests (à la github), and merges could

> > also be done with standard tools like kdiff3.

> Yes, git support is IMO a must have. The major advantages I see would be

> - not losing commit history when sr'ing/merging or linking packages

Actually, this would be also a not acceptable regression, if you do not

see anymore when you have merged requests. So, there would be a concept needed how to tag and handle reverts.

> - locally doing atomic (readable) commits, pushing them squashed to OBS

> to avoid re-building every commit.

Oh, well, priorisation system should take care of that.

> - offline work is possible when OBS is down (which happened very often

> in the last time)

actually, offline work (offline build) is supported meanwhile in osc. And

dependency calculation is still required server side in any case, independend of the used src revisions system.

> - fetching several package clones (regardless their names) into the same

> working copy to speed up testing/comparing

we would need that anyway in seperate build environements or we can handle

the parallel build on server.

> - rebasing commit history to have nice commit series to be pulled from

> the major projects (devel, factory etc.).

...

Do not get me wrong, I am not against an additional git backend. But there are _MANY_ of unresolved problems with that and there do not even exists concepts at all how to solve all the regressions and major problems a git backend would have.

But everybody can take of course the existing code and work on it. But the resulting code needs not to work on a single small package, but scale also for projects like openSUSE:Factory.

The api test suite may be helpfull to see _some_ of the problems when you replace the backend.

> cu,

> Rudi

> > On my last team which was organised around a central svn server, I

> > used git-svn for two years and it gave me most of the advantages of

> > decentralized development without anyone else on the team even

> > needing to know. Then some of the other guys started getting

> > interested, and it allowed us to collaborate in a decentralized way

> > independently of the central svn server:

> >

> > https://twiki.innerweb.novell.com/pub/PSO/GitHOWTO/_801___Screenshot.

> >

> >png

> >

> > When's the next hackweek? ;-)

Adrian Schroeter

SUSE Linux Products GmbH

email: adrian@suse.de