[haiku-development] Re: Moving away from Subversion, pt. 2
- From: Niels Reedijk <niels.reedijk@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 30 Jun 2010 22:14:32 +0200
Hi,
On 30 June 2010 20:06, Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
> - in the 'Decentralized with Shared Mainline' workflow, committers may work
> on branches in the central repo or in their own repository/ies. Peer-review
> and -programming would require that developer-specific repositories are
> accessible by others, otherwise the development isn't visible until the
> developer pushes the commits into the central repository.
I think this should be the main model (for now). We have a main branch
(let's call it 'trunk') with more or less the same policies we
currently apply to the svn trunk. So the same group of commiters, with
the same 'push it when it's done' mentality. I think the tool probably
should actively enforce that mentality, like how bzr allows you to
have a checkout that pushes every commit when it happens. This as
opposed to git and hg that first commit locally, and then you need too
push with the occasional merge/rebase cycle. (Yes, it is only one
extra command, but I am certain in our repository most changes
will/could be pushed right away and we should encourage that.)
As for the version branches, those should be dedicated branches only
to be used by the release coordinator(s). With the way we worked last
time, I think the tool should have the ability to cherry-pick
changesets that are applied to the trunk.
> - the 'Decentralized with human gatekeeper' workflow is a tough one to
> implement if there aren't enough devs motivated to be gatekeepers. Judging
> by the amount of peer-review we get done, I suppose this might be difficult
> for us.
Agreed.
> - the 'Decentralized with automatic gatekeeper' workflow is probably less
> problematic to implement, but the result would be less valuable than with a
> human gatekeeper (i.e. most probably it'd be that haiku still builds with
> the incoming changes applied).
What would that gatekeeper do? Style check?
> Obviously, none of these workflows are fixed, they can (and probably need
> to) be adjusted to form our own workflow.
>
> Here are a couple of questions that hopefully can help getting an idea:
>
> - where should branches live, in the central repository, in local
> repositories, or in both (depending on how long-lived they are meant to be)?
>
> - if there are branches in the central repository, should they be available
> as individual repositories (such that they can be pulled individually), or
> do we pull the whole thing always?
Today I was thinking about when exactly it is useful to have the full
history on your hard drive. I sort of came to the conclusion that the
answer is probably none. (You don't need full history when you work
offline and commit). I think that the tool we pick should at least
support shallow checkouts, like svn's working copies, because in my
view this is going to be the main usage model.
> - do we try to avoid that using a DVCS moves some part of the development
> into the dark (into local repositories) or do we trust that devs will find
> the way to publish/share their repos that fits them best?
I think we should a la git-hub have a system where developers can
create (and delete) their own work in progress branches. This probably
requires a sort of front-end, because I feel little for everybody
ssh'ing into vmsvn.haiku-os.org and meddle around there.
We could have a policy that is built on feature branches, where a
number of people work on one feature (coordination via email) and
personal branches, where only one developer is responsible for what
happens. So next to the policy that whatever is ready goes into trunk
immediately, we can also have the policy that whatever is work in
progress (and could use eyes), should be shared.
> - as a counter measure to decreased visibility, is it a good idea to
> support shared, dev-specific repositories on the server, with e.g.
> potential integration into haiku-commits?
See above.
> - how do we try to make it easier for external contributors
> (non-committers) to get their patches reviewed and applied - is the
> technical improvement of using a DVCS enough or do we need something better?
I have thought about this too. Every DVCS has their specific format
for packing patches. Hg has bundles, for example. With the current
patch functionality on Trac we can at least mark these patches. The
next step could be to write an extension/script for the tool we are
going to use to automatically push and pull patches from
dev.haiku-os.org.
Example of bundling all changesets not in trunk and attaching it to a ticket:
bzr trac push #3523
Getting the patches from a certain ticket and apply them to the local
repository:
git-trac pull #4439
> - is Trac a sacred cow or are we prepared to look for something else if the
> DVCS of our choice doesn't work well with Trac?
I think that any non-svn repository of our size has not been used with
Trac, so only testing will tell. There is some knowledge about Trac
in-house (that would be me), and I know that for example mercurial has
a special place in the heart of Trac developers so with the right
contacts we might be able to mobilize them too. As for others, every
tool has its own web environment, we should see how far we could get
with that.
> - during the import of subversion's history into the DVCS, would it be
> acceptable if some part of the history of renamed and/or copied files gets
> lost? Would keeping a mirror of the subversion repo be enough to compensate?
I actually think so, but I think you can get quite far. There is a
major rename around 10700 (iirc) and everything before that might be
weird, but for the rest I think both the hg and git imports are quite
good. If bzr's isn't, we might try to tweak the tool to see what we
can do.
Regards,
N>
Other related posts:
