On Thu, Sep 25, 2008 at 3:39 PM, Adrian Schröter wrote:

On Thursday 25 September 2008 21:58:22 wrote Archie Cobbs:

...

The "how to verify and fix broken links?" thread brought up a question I've always wondered about....

Why does osc not-exactly-duplicate the functionality of svn, instead of just letting the user use svn directly?

In other words:

- Use svn for all checkout, diff, commit, merge, etc. operations

svn has no functionlity for source links for example. So all the derived versions would not be possible and manual work would be always needed, not only when conflicting changes exist.

What do you mean by source links functionality? Clearly svn can't do "osc up -e"... so that particular functionality would have to remain part of osc.. But wouldn't it still be possible to use svn for the stuff svn can do? Apologies if I'm missing something... -- Archie L. Cobbs -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Now my own 2 cent:

...

2. There's pros and cons for hostig a distro, a collection of large random data (comptressed tar archives) plus relatively small patches in svn

A strong point in the past against it was that we preferred relying on just the filesystem as a database instead of svn on mysql or such. We had plenty of experience from the autobuild system how to do that resonably well, and much faster than any full-featured revision control --- the features of which never matched what we needed.

But still it might be an interesting point. For example, connectiva linux hosted their whole distro in a subversion tree, not sure what happened when they became mandriva.

redhat and pld still have their whole distro in CVS.

imho the weakest point of svn in the past was the space requirements of the working copy. but osc went the same way as SVN so that cant count either.

svk got a nice working copy format on top of the svn libraries.

The OBS is so to say already split in two parts: a) sources and the handling of that b) binaries and building/running/testing/packaging/images Even large projects like the distro is handled like a large source tree in a revision control system. Also, you handle a distro like in a revision control system. E.g. - there is a main trunk, called here Factory. Example: openSUSE:Factory - there are branches, called here Releases. Example: openSUSE:11.0. When they are released, they are in maintainance mode and are handled like release branches. Adding some smart capabilities to source code/link handling would help working with the revision control part of the system. It would mean that then it is also more like in a revision control system. That means: - making a openSUSE:11.0 at a certain stage is then also expressed by some branch/copy operation. The Information of this copy will be kept, like in revision control - all kinds of Information that have to do with reproducing a result must be also under revision control. Example: meta data. prjconf is only valid with a specific revision, so it should be under revision control. - features like links must have a context. That could be a specific revision. Example: + openSUSE:Factory/kernel-default links to openSUSE:Factory/kernel-source. openSUSE:Factory is a "trunk", so the link links to a "trunk" + openSUSE:11.0/kernel-default links to the revision of openSUSE:11.0/kernel-source. Because openSUSE:11.0 is a branch, the "revisioned link" would then automatically work, when openSUSE:11.0 is branched off openSUSE:Factory.

...

btw, as packages often come as sources with patches, I think if any revision control system, then git might be a better option.

the revision control system doesnt really matter here. as they handle them all the same.

Yes and no. We have pattern of usage that are like a revision control system. So people expect it to behave like one.

the only pro for git is that our backend storage is pretty close to a git repository. so the code could be adapted to be compatible.

though we would need our own git daemon: 1. to apply the same access control we do in api atm. 2. to trigger the scheduler events. 3. to update the caches in api for metadata e.g.

So you also propose to split off the revision control system of OBS to something known like git? Your proposal to git is, if I understand you correctly, because git does already nearly the same as the current implementation inside OBS, right? Martin -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thursday 25 September 2008 23:22:51 wrote Marcus Rueckert:

On 2008-09-25 23:14:55 +0200, Susanne Oberhauser wrote:

...

1. IMHO branch merge handling with svn is quite painfull as you need to know yourself what you branched of and what you've already merged in, at least last time I tried.

svn log --stop-on-copy

1.5 got merge tracking

but this is not a system to keep a branch automatically up2date and just storing your changes like the source links does. There is also no functionality for handling all the functionality like topadd or automatic changelog handling like planned.

...

Maybe a system that's designed with recieving and merging in patches, like git, might do a better job here.

So I believe we are doing more and other things than svn.

our merge handling is ... in friendly words: less than optimal.

the merge handling is okay, the conflict handling is missing ;) The conflict handling is definitive something we need, and when we can take it if from something else, it would be great. But it is pointless to discuss the current source handling, when all other solutions do not even support the stuff where we have detail problems. We would only loose and not gain anything, just lots of additonal work to add lots of functionality on top of it what will cause for sure new problems. Better fix the missing 1% instead of rewriting the other 99% ;) bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Friday 26 September 2008 20:47:10 wrote Lars Marowsky-Bree:

On 2008-09-26T06:58:42, Adrian Schröter wrote: ...

...

But it is pointless to discuss the current source handling, when all other solutions do not even support the stuff where we have detail problems. We would only loose and not gain anything, just lots of additonal work to add lots of functionality on top of it what will cause for sure new problems.

Better fix the missing 1% instead of rewriting the other 99% ;)

That's easy enough to say after one has rewritten the remaining 90% of an SCM already - as a mid- to long-term maintenance decision, that isn't the best choice, and something which we should try and overcome.

The base of our system is several years old (dunno if it was there 11 years ago already), it has proven to be stable, maintainable and also very important, performant enough (I doubt svn is, after the problems I have seen when KDE moved (Mandriva lived with these and they have also not the load we have on the system, since they have a closed system, where rebuilds need to triggered manually, so this is also no argument)).

There's really no good point why we need to have our own SCM, whereas there's a pretty strong point to reuse an existing one, possibly with extensions - but both git or mercurial _can_ be extended with modules.

You are aware that this modules would be the majority of important code for us. We have currently ONE interface to request the classic source handling, dependency calculation, project handling, rights management, build counting and so on all handled by the source server. It handles also specific sources differently to avoid otherwise necessary automatic source commits, which would IMHO a bad design. We have really a special use case, not matching to the others where svn and friends are designed for. When we would start on a move now, we would have end of next year maybe the same status as now, but no clean, single interface anymore and I fear also a less secure setup. And apart from this I think end of next year the next SCM management tool is cool and the discussion will start again ;)

We'd still gain all the other features - bisect, history browsers, commands we're used to, etc.

Writing a wrapper from our interface to these clients would be a better approach here. But it would not help us with the specialitiest we start to discuss here in this thread. have a nice weekend adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Fri, Sep 26, Lars Marowsky-Brée wrote:

...

But it is pointless to discuss the current source handling, when all other solutions do not even support the stuff where we have detail problems. We would only loose and not gain anything, just lots of additonal work to add lots of functionality on top of it what will cause for sure new problems.

Better fix the missing 1% instead of rewriting the other 99% ;)

That's easy enough to say after one has rewritten the remaining 90% of an SCM already - as a mid- to long-term maintenance decision, that isn't the best choice, and something which we should try and overcome.

Well, I totally agree with you in general (reuse existing code), but as everything is already almost (90%?) done, it would be insane to start again, wouldn't it? Wouldn't that also mean, that there'll be a complete new API to access the OBS? -- With best regards, Carsten Hoeger