[10] in athena10
Re: Version control for Athena 10
daemon@ATHENA.MIT.EDU (Tim Abbott)
Fri Dec 7 16:15:32 2007
Date: Fri, 7 Dec 2007 16:15:20 -0500 (EST)
From: Tim Abbott <tabbott@MIT.EDU>
To: Greg Hudson <ghudson@mit.edu>
cc: athena10@mit.edu
In-Reply-To: <200712051647.lB5GlurS000780@equal-rites.mit.edu>
Message-ID: <Pine.LNX.4.64L.0712071607430.25874@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
I don't have a strong opinion on this matter, but I could see the DVCS
option being really nice for people working on building Athena packages
for Macs or other Unix platforms. Since I've heard grumblings about
people doing such a project around SIPB repeatedly over the last few
years, and there are a large number of people using Mac laptops around
campus, it seems that this might present a near-term advantage.
-Tim Abbott
On Wed, 5 Dec 2007, Greg Hudson wrote:
> 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.
>
