[5877] in Release_7.7_team

home help back first fref pref prev next nref lref last post

New Athena Subversion repository conventions

daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Nov 8 10:40:33 2007

Date: Thu, 8 Nov 2007 10:39:56 -0500
Message-Id: <200711081539.lA8FdueT031746@equal-rites.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@MIT.EDU
X-Spam-Flag: NO
X-Spam-Score: 0.00

I've converted the Athena CVS repository to Subversion, hosted at
svn+ssh://svn.mit.edu/athena.  All of the relevant developers should
have commit access.

I don't believe it's sending out commit logs yet, and I haven't set up
a sync into AFS.  I plan to fix those after Garry gets back.

When we make commits into CVS, we need to also commit them to the
"trunk" in svn if they have any relevance to Athena 10.  Reviewing the
recent commits for the patch release:

  NO - Bob's version script for Solaris
  NO - Bob's Firefox version update
  YES - Andrew's fix-xconfig change for widescreen monitors
  YES - Andrew's xconf athinfo query
  YES - Andrew's getcluster change to query public-linux
  NO - Greg's /opt/mono symlink on Solaris
  NO - Greg's numpy build materials

When committing to the svn repository, please use the following commit
log structure, borrowed from the Subversion project:

[[[
General summary of the commit; can be omitted if it's a commit to one
file or otherwise obvious from the per-file changes.

* path/to/file1: Change to a non-structured file.
* path/to/file2 (symbol): Simple change to a structured file like C
  source code.
* path/to/file2
  (symbol1): Change to a symbol within a file.
  (symbol2, symbol3): Similar change made to multiple symbols within a
    file.
]]]

The [[[ and ]]] are not part of the commit log itself, just a
convenient way of delimiting a commit log inside an email message.
(That's also a convention borrowed from the Subversion project.)

Log messages like these make it easier to make sense of atomic commits
made across multiple files.  However, remember that commit logs are
about logging changes, not documenting how stuff works.  That's what
comments are for.  In particular, if you are adding new material, do
not describe in the commit log how it works; just describe in very
vague terms what it does.

Simple changes can have short log messages according to these
conventions.  Stuff like:
[[[
* athena/bin/getcluster/getcluster.1: Fix a typo
]]]
is perfectly acceptable.

home help back first fref pref prev next nref lref last post