14 Feb
2012
14 Feb
'12
15:20
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