Mailinglist Archive: opensuse-buildservice (214 mails)

< Previous Next >
Re: [opensuse-buildservice] OBS and git
On Tuesday 14 February 2012, Adrian Schröter wrote:
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

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.

Of course always "git merge --no-ff" into factory/master.

- 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.

My major point here is that changes across different topics should never
be mixed into the same commit. But svn-like VCS leads to do it the bad
way. Submit requests could be reviewed much easier if you see all the
atomic commits behind a huge submit-request.

- 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.

Is it possible to commit local only?

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.

For now I just do "git init" within ocs working copies. It does already
much of what I need allthough it can be confusing. An intermediate next
step could be to improve the client side only by providing a git-osc
similar to git-svn.
Finally having git backend on OBS side someday would be really nice.


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? ;-)

To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups