Ruediger Meier (sweet_f_a@gmx.de) wrote:
On Tuesday 14 February 2012, Adrian Schröter wrote:
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.
My habits are the same as yours, Rudi. I guess Adrian's point is that normally the changes required within the osc working directory are tiny and really simple (e.g. update .tar.bz2 / .changes / Version number in .spec file). Although when working on the tests for obs-service-tar_scm, I had to develop the full test suite inside this directory, so I had to do 'git init' otherwise it would have been a disaster.
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).
Trying to summarize a few different threads of discussion from the last few days: - everyone seems generally agreed that, if (and only if!) the implementation challenges could be solved, having git frontend and backends for OBS would bring a lot of advantages (these are very nicely documented at http://en.opensuse.org/openSUSE:Build_Service_Git_Backend) - there are a LOT of challenges to overcome before this could happen, and some still have no known solution according to Adrian - some really good work was started in 2009 as documented on the wiki page Remaining questions: 1. Is the *outcome* of the GSoC 2009 project documented anywhere? 2. Is anyone still working on it? 3. Is bsgit still usable? Doesn't seem to have changed since 2009. I'm also guessing noone has spare time to dedicate to such a big project right now. So my suggestion is to take a "divide and conquer" or "softly softly" approach: - establish a central location (e.g. the wiki) for documenting and working on the existing problems - ensure that this location contains past work, current status, and future work (it doesn't have to be polished, just reasonably accurate) - classify future work items into two separate buckets: + problems we know how to solve, but which haven't been done yet + problems for which there is still no solution (BTW this last item is particularly important, otherwise people could waste time implementing something which might not work in the real world e.g. due to scalability issues or some of the other concerns Adrian already mentioned.) If we had this documentation then people would be able to choose a small chunk of work whenever they have a bit of spare time, and then hopefully we could maintain a small amount of momentum. So if noone has any objections, I am happy to start working on updating the wiki - but then I would need some help, because with the exception of what was recently stated on these lists, I am missing a lot of information about known problems with moving to git. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org