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@suse.de) 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@suse.de