[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Package "ownership" per team, and the use of `mr' to handle this.



On Mon, 8 Dec 2008, Charles Plessy wrote:

Since the discussion starts, I will disclose my ideas before testing them :)
This is untested ideas that may lead nowhere. I will not propose Debian Med to
invest time in structural rearrangements before having tested my ideas and
discussed them better.

I admit that I also thought about restructuring because the current structure
does not seem to scale any more.

We accumulate a lot of stuff in the `tags' directories of our repository. It
does not take space in the central SVN database but it does on our hard drives,
to the point that it will start to annoy people who want to checkout
everything.

Solution A: change the structure of our repository, from
           "package/{trunk,tags,branches}" to "{trunk,tags,branches}/package".

Sounds reasonable because the effort for restructuring seems to be low and
changing habits for developers is minimal.

Solution B: migrate to a version control system that does not have such an
           overhead for tags.

Hmmm, smells like you want to start a VCS flamewar. ;-)
IMHO we should not rush really fast into this direction.  I'm currently start
to sneak into git (with my personal "hello world"-package xteddy) and try to
gather some experiences.  I'm afraid that several people will not really like
to be forced to switch their VCS - at least it just drains some time to learn
from people.

Problem with solution B is that typical alternatives to Subversion do not have
partial checkout facilities.

I do not really understand what you mean with "typical alternatives to Subversion".
IMHO we should switch to a DVCS (if we switch at all) which is perhaps not
"typical" because Subversion is no DVCS.

As you may have guessed, it would probably be a good opportunity to switch to
git if we agree that it is worth the effort.

If there is a consensus that might direct into "Solution B" I would propose a
"soft migration path" which allows both repositories for a (perhaps long)
transition period.  Debian Science also allows both.

Nevertheless, the `mr' system
could also work with our current repository. This would actually provide some
kind of migration path.

So mr might be helpful in the migration process.

None of this is tested yet, but I hope I can play on this during my vacations.

Have nice holidays ;-)

          Andreas.

--
http://fam-tille.de


Reply to: