Mailinglist Archive: opensuse-buildservice (269 mails)

< Previous Next >
Re: [opensuse-buildservice] Why not just use SVN?
  • From: Martin Mohring <martin.mohring@xxxxxxxxx>
  • Date: Fri, 26 Sep 2008 02:47:53 +0200
  • Message-id: <48DC3139.3020303@xxxxxxxxx>
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups