[9] in athena10
Version control for Athena 10
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Dec 5 11:48:08 2007
Date: Wed, 5 Dec 2007 11:47:56 -0500
Message-Id: <200712051647.lB5GlurS000780@equal-rites.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: athena10@MIT.EDU
I talked with Steve and Catherine about the collaboration and they
haven't raised any red flags. They are also amenable to us using git
or another DVCS instead of svn if there's a good reason for it. So
let's discuss this issue in more depth.
Anders wrote:
> If you have something like Git, you can keep the upstream sources
> and packaged sources in two separate branches (or even
> repositories), and freely merge patches between them.
My reservation is that even with good merging support in the VCS tool
we use, this feels like an unnecessary extra step when doing
day-to-day work on the Athena sources. Every time we make a change to
the platform-independent Athena sources and want to push it out, the
developer would have to do two steps in two different checkouts: first
make the change to the platform-independent source, then merge the new
code into the Debian package source and create a changelog entry.
I also don't think adding a debian directory really damages the
platform-neutral nature of the sources. If you're not creating a
debian package from the source, you just ignore the directory and
build in a different way.
For the hard cases like bash where we have to modify the upstream
source packages, no version control tool is going to do the job since
there are multiple upstreams and multiple products. The Debathena
solution of writing a custom script per package is fine, but it's not
going to matter which tool we use to store the script and patch.
> A distributed VCS, of course, also has the advantage that people not
> involved in the project can utilize the VCS in the same first-class
> way that project members do.
Agreed, and this is a motivator for adopting a DVCS in general.
I could see using git as a sort of pilot or technology leader thing.
The usual counterweight to using a DVCS is that SVN has better Windows
support and IDE integration, neither of which applies to Athena. My
concerns are:
1. This could become an albatross if nothing else in IS&T ever uses
git.
2. This could set back the project since it requires learning and
adapting to a new tool.
Currently, I would prefer to use svn and treat our packages as Debian
native.
> https://wiki.ubuntu.com/NoMoreSourcePackages
> https://wiki.ubuntu.com/NoMoreSourcePackages/GitImpl
This is cool reading, but is mostly trying to solve two problems we
don't have:
1. (Base document) People uploading source packages without
committing their changes to version control. They propose
forbidding source package uploads, instead forcing source updates
to be done through a back-end mechanism which checks out from
version control.
2. (Git implementation) Keeping Debian and Ubuntu packages in sync
even though they use disjoint debian control information. They
do this by keeping the patched package source in one repository
and the debian directory in another. The package source can then
be freely merged between the Ubuntu and Debian maintainers, while
the debian control information is kept separate.
