On Thu, Oct 25, 2007 at 09:27:39AM +0200, Klaas Freitag wrote:
On Wed, 2007-17-10 at 10:28 +0200, Michael Schroeder wrote:
On Tue, Oct 16, 2007 at 02:30:47PM -0500, Michael Wolf wrote:
Do the improvements listed at http://en.opensuse.org/Build_Service/Roadmap#Milestone_Daffodil_.28Vers ion_1.0.29.2C_April_2008 imply distributed revision control? Many people, myself included, want this very much.
Hmm, this is more a tool issue than something we can do on the build service. The build service currently stores the sources pretty much the same way as git does, except that it uses md5 sums instead of sha1 sums to identify a release (this is for historical reasons). I'm thinking about switching it over to sha1 so that it is compatible to git, but I need to find some spare time for this.
If we could use git (with all of its features, of course) in place of "osc diff", "osc commit", etc., that might be OK, although it seems like more work in the long run than just using revision control in the first place. I think that's reasonable and would like to have that for the reasons
On Thursday 25 October 2007 01:08, Michael Wolf wrote: that we do not have to maintain git ourselves, that people of all colour continue to ask "do you use a real source control system?" and we can easily answer 'yes' than and finally that we hopefully benefit from existing tools that set up on git. Hopefully, because I have nothing special in mind. Anybody else?
I am sometimes asked, why osc was written in the first place, and why the existing subversion client was not used. The answer is twofold. 1) A subversion client is not compatible to our similar but "reduced" api, it expects a WebDAV server, with extensions even. 2) hacking the massive codebase of a subversion or even maintaining a branch of it to work with the BS seems like a big task. But at least 50% of osc code is code that has nothing to do with version control (and don't fit into svn), and most of the other 50% (version control specific) are too trivially to implement. Of course, the non-version control parts *could* be implemented in a separate tool. I am sometimes asked, why the BS doesn't offer an api which is compatible to WebDAV. Well, it was designed ground up, why not, and grew to a more complex thing later, I personally see the shortcomings but believe that it would have been more work to use something existing. As the question goes, whether to switch to some distributed version control paradigm (whatever its name), I can't see a projected switch as a pure advantage. On the contary, I believe that there are two parties with different interests: one that prefers the distributed paradigm, and one that prefers the centralized paradigm. I personally think that both approaches make sense. But I know for sure that just as there are people who feel severely hindered by a subversion-like approach, there are others that would hate to work with the git "pile of crap". I estimate that the git addicts are a minority -- but who knows? Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development