Mailinglist Archive: opensuse-buildservice (214 mails)

< Previous Next >
Re: [opensuse-buildservice] OBS and git
  • From: Adrian Schröter <adrian@xxxxxxx>
  • Date: Tue, 14 Feb 2012 14:24:32 +0100
  • Message-id: <1827673.3n88xzgWLf@scherben>
Am Dienstag, 14. Februar 2012, 14:14:21 schrieb Ruediger Meier:
On Tuesday 14 February 2012, Adam Spiers wrote:
Adrian Schröter (adrian@xxxxxxx) 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

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

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.


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:


When's the next hackweek? ;-)
Adrian Schroeter
SUSE Linux Products GmbH
email: adrian@xxxxxxx
< Previous Next >
Follow Ups