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:
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 settings.
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.
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.
cu, Rudi
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:
https://twiki.innerweb.novell.com/pub/PSO/GitHOWTO/_801___Screens hot.
png
When's the next hackweek? ;-)
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org