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 16:20:36 +0100
  • Message-id: <2323500.74VRliQzJ2@scherben>
Am Dienstag, 14. Februar 2012, 15:18:32 schrieb Ruediger Meier:
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:
...
- 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.

that is not a solution.

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

Frankly, I see this really as a minor thing during packaging work.

If you are unsure about your work, you branch anyway before submitting.

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

No. But again, I think this is a minor thing. It is way more important to have
offline builds to be able to do packaging work.

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.

Well, if that works for you that is fine. But using git as repo is a complete
different level of problems. Just because git offers a feature for you it does
not mean it offers all the features (revision counting, on-the-fly-merge,
revision tracking, shadows sources and so on) the obs needs.

Anyway, since people always only say that git would solve everything but no
one works on it, I am stopping now here ;)

Feel free to work on it and I promise we will help you run into problems...

bye
adrian

--
Adrian Schroeter
SUSE Linux Products GmbH
email: adrian@xxxxxxx
< Previous Next >
Follow Ups