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