Re: [Simulavr-devel] Discussion: how to proceed with thedeveloment on GIT repo?

[Joerg Wunsch]

As Onno Kortmann wrote:

> I discussed the last developments with Thomas and I was using git
> specifically because some of you had problems with me having commit
> access.

Well, it would have made sense to fix the commit access problems
then...

> That said, and to answer the question about git's advantages: git
> easily supports multiple branches within one repository, ...

This is about true for *any* VCS I know of, including (again) the
venerable CVS.

The major cost of a branch is to eventually merge the branch back once
the time has come.  This is where I'd see the real problem about
branching.

> People who clone the repo get everything and can look at the 
> states of the various branches. 

For this, it shouldn't even be required to clone a repository, just
checking out the branch (instead of trunk or HEAD) would suffice.

> Git surely does not replace communication on the ML here, but I feel
> it gives people a great incentive to contribute if a main dev would
> give commit access or, at least, pull the changes from some other
> repository (such as mine on github) into the main one.

One real disadvantage I'm seeing with the "offline" git version is
that there are no commit messages relayed through the mailing list, so
nobody except the core developers do know what's going on there.

> This of course would create a fork but I think this is always the
> case if you want to support a stable and a development version. And
> that, I think, would be very good idea now.

I don't see a stable version so far.  There hasn't been an official
simulavrxx release for more than 4 years now (only one that is named
"simulavrxx_klaus_00.tar.bz2" last year).

But of course, if the things you are working on really aren't stable
so far, then the costs of a branch would be justified -- but that only
makes sense if there is a kind of schedule (not necessary by date, but
at least by some kind of TODO list or so to walk down) for eventually
merging the new functionality back into the mainline code.  Otherwise,
it will still be a fork.  And no, please don't expect anyone else to
do the merge, the only one who is able to merge is/are the
developer(s) who is/are actively working on the branch.

> I think even you decide [...]

There is no "you" whom you could address here.

This "you", that are: Onno, Thomas, Michael, maybe Joel.  Klaus said
Good-Bye many months ago, and has not been seen ever since.  I don't
even know whether he's still following this mailinglist, maybe.  Eric
and me are only here to take care of "household" things, to offload
boring project maintenance tasks from the actual developers.

> It would be nice if the project would only have a single point where
> the latest source code is, and this should be the savannah
> repository.

So there appears to be general consensus about this.

> ..., but git at least helps as much as it can in 
> doing merges.

Again, that's essentially true about every VCS I've seen, though
arguably, it's not the brightest side about CVS.  But then, if it
comes to a truckload of conflicts, you're out in the rain for a manual
merge with any VCS.

> Also, it supports local development, which is very important if a
> dev does not have commit access to the central repository.

As there are only very few active developers anyway, they should
really go with master repository access instead.  I think local
development does more of a mess then than it would be helpful.

(old simulavr-0.1 codebase)

> If wished, I volunteer to import the old code base into a git
> repository. It boils down to a call of 'git cvs-import' with the
> correct parameter set.

I'd like to first see some consensus about the VCS to use.  Savannah
offers CVS, SVN, and git, so that would be the possible candidates.

Once this decision has been made, plans should be crafted how to
migrate the old repository (in case the new decision will not be CVS),
and migrate the stuff from Onno's offloaded git repository back.

Again, this is just a proposal, it's you (the active developers) who
have to decide about the path to take.

> As its code base is completely independent of the simulavrxx stuff,
> it is probably a good idea to have an own separate git repository
> for it. Without any simulavrxx stuff. It hope savannah supports
> that.

It depends on how git repositories are organized.  For CVS or SVN,
savannah only offers a single repository per project (plus an
additional CVS repository for the project web pages).  So far, both
sub-projects have been organized as two top-level directories within
that single repository, so the only shared information between both is
the repository infrastructure itself which is quite opaque to the
developers (as it is handled by the Savane web interface and/or the
Savannah admins only).  The only consequence I'm seeing out of this is
there is only one possible commit mailinglist, and with SVN, there
will be a single revision number space for both.  (Don't know about
git here, CVS was/is different as each individual file carries its own
revision number space.)  If simulavrxx continues to develop with at
least the pace it does by now, I don't see any need to ever commit
anything against to the old simulavr codebase though, so its presence
in the tree would be mostly to keep the VCS history of that old
project intact.
-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)