On Tuesday 14 February 2012, Adrian Schröter wrote:
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.
Oh, then I haven't understood the problem.
- 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.
That's the way I do it but it doesn't change the fact that currently branching is a very slow remote operation, check out again, switching working copy, etc. And moreover after sr the commit history is lost,
- 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.
It might be a minor thing from OBS admin's view. From developers view I wouldn't leave the room as long as my working copy is dirty. And I wouldn't even start to work if my VCS does not have full functionality yet. That's why I _workaround_ with "git init". Just pity that I can't save my local git history directly on OBS so I need to hope that I don't make mistakes when manually synchronizing my work between local git and remote OBS.
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...
Hey, I don't want to force you moving OBS to git. Just mentioned that it would be a real improvement (at least for the packagers who care as much about history and commit style like me). cu,Rudi -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org