CVS commits and logs

CVS commits and logs

[Eli Zaretskii]

It looks like some people are not aware of the guidelines about CVS
commits and commit logs, or maybe those guidelines are ambiguous or
unclear, because the style of the log text differs considerably from
one maintainer to another, and hints on commit procedure that is not
according to what I know.  See the few examples below.

I think Richard should decide what is the canonical form and what are
the guidelines that everybody should follow, and we should then
describe those guidelines in some file in admin/.  I describe here
the rules I know about, as a starting point:

  . CVS log entries should be simply the ChangeLog entries with the
    file name and the leading TABs stripped.  It is okay to reformat
    and refill the text to make a better use of the line real estate
    after the leading TABs were removed, but otherwise the text should
    remain intact (but see below for an exception).

  . Each file should be committed separately, even if the changes are
    related, and the CVS log entry should be for the changes in that
    file only.  In particular, the modified files and the ChangeLog
    file with the appropriate log entry should be committed separately
    (thus the CVS log entries for ChangeLog files should never include
    log entries for the modified files).  Exception: it is okay to
    commit several changes to a single ChangeLog file in one "cvs ci"
    command if those changes are related to the same feature/bugfix.

  . Since the previous rule separates the text for similar or related
    changes in different files, entries that say "Ditto." or otherwise
    refer to text for other files' entries should be rewritten to be
    self-contained in the CVS log.  This is an exception from the
    first rule, which says that the ChangeLog text should generally
    remain intact.

  . The ChangeLog files should be committed with an empty log message
    (unless this is a real change in the ChangeLog file itself, not an
    addition of log entries).

Here are some random examples of the various styles we currently have
in CVS log (the entries are indented 2 spaces to the right):

lisp/ChangeLog:

  revision 1.10244
  date: 2006-11-03 13:54:32 +0000;  author: ramprasadb;  state: Exp;  lines: +4 -0
  *** empty log message ***
  ----------------------------
  revision 1.10243
  date: 2006-11-02 23:46:14 +0000;  author: monnier;  state: Exp;  lines: +8 -0
  (server-auth-key): Remove.  Replace by a process-property.
  (server-start): Don't remove the file of the previous process, but
  instead clear out the place for the new file.
  (server-start): Set the :auth-key property.
  (server-process-filter): Use the :auth-key property.
  ----------------------------
  revision 1.10232
  date: 2006-10-30 21:34:15 +0000;  author: cyd;  state: Exp;  lines: +8 -0
	  * tutorial.el: Move defvars to avoid bytecomp warnings.
	  (tutorial--find-changed-keys): Check if viper-current-state is
	  bound before using it.
	  (help-with-tutorial): Check if viper-tutorial is defined before
	  using it.
  ----------------------------
  revision 1.10200
  date: 2006-10-18 14:05:16 +0000;  author: jhd;  state: Exp;  lines: +6 -0
   * term/x-win.el (res-geometry): Don't set geometry from Xresources
   to default-frame-alist if default-frame-alist already contains
   widht/height.
  ----------------------------
  revision 1.10182
  date: 2006-10-11 06:47:35 +0000;  author: monnier;  state: Exp;  lines: +359 -0
  Merge from upstream, upto version 5.22.
  After 5.0:
   `cperl-add-tags-recurse-noxs-fullpath': new function (for -batch mode)

   Fine-grained changelog:
  `cperl-hook-after-change':      New configuration variable
  `cperl-vc-sccs-header': Likewise.
  `cperl-vc-sccs-header': Likewise.
  `cperl-vc-header-alist':        Default via two preceding variables
  `cperl-invalid-face':   Remove double quoting under XEmacs


lisp/faces.el:

  revision 1.354
  date: 2006-09-14 23:54:44 +0000;  author: rms;  state: Exp;  lines: +1 -1
  (mode-line-faces): Group mode-line instead of modeline.
  ----------------------------
  revision 1.351
  date: 2006-06-28 23:29:26 +0000;  author: nickrob;  state: Exp;  lines: +1 -1
  * help-mode.el (help-xref-symbol-regexp): Add property as a keyword
  for ignoring links.

  * faces.el (read-face-name): Use it.
  ----------------------------
  revision 1.344
  date: 2005-11-20 15:24:27 +0000;  author: cyd;  state: Exp;  lines: +5 -11
	  * faces.el: Revert 2005-11-17 change.  :ignore-defface is now
	  handled automagically.
  ----------------------------
  revision 1.321
  date: 2005-06-22 01:22:40 +0000;  author: miles;  state: Exp;  lines: +1 -1
  Revision: miles@gnu.org--gnu-2005/emacs--cvs-trunk--0--patch-438

  Rename vertical-divider face to vertical-border

  2005-06-22  Miles Bader  <miles@gnu.org>

     * lisp/faces.el (vertical-border): Renamed from `vertical-divider'.

  2005-06-22  Miles Bader  <miles@gnu.org>

     * man/display.texi (Faces): Change `vertical-divider' to `vertical-border'.

  2005-06-22  Miles Bader  <miles@gnu.org>

     * src/xfaces.c (Qvertical_border): Renamed from `Qvertical_divider'.
     (realize_basic_faces, syms_of_xfaces): Update references to it.
     * src/dispextern.h (enum face_id): Rename `VERTICAL_DIVIDER_FACE_ID'
     to `VERTICAL_BORDER_FACE_ID'.
     * src/dispnew.c (build_frame_matrix_from_leaf_window): Update references.
  ----------------------------

Re: CVS commits and logs

[Eli Zaretskii]

> Date: Sat, 04 Nov 2006 13:40:21 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
>   . CVS log entries should be simply the ChangeLog entries with the
>     file name and the leading TABs stripped.  It is okay to reformat
>     and refill the text to make a better use of the line real estate
>     after the leading TABs were removed, but otherwise the text should
>     remain intact (but see below for an exception).
> 
>   . Each file should be committed separately, even if the changes are
>     related, and the CVS log entry should be for the changes in that
>     file only.  In particular, the modified files and the ChangeLog
>     file with the appropriate log entry should be committed separately
>     (thus the CVS log entries for ChangeLog files should never include
>     log entries for the modified files).  Exception: it is okay to
>     commit several changes to a single ChangeLog file in one "cvs ci"
>     command if those changes are related to the same feature/bugfix.
> 
>   . Since the previous rule separates the text for similar or related
>     changes in different files, entries that say "Ditto." or otherwise
>     refer to text for other files' entries should be rewritten to be
>     self-contained in the CVS log.  This is an exception from the
>     first rule, which says that the ChangeLog text should generally
>     remain intact.
> 
>   . The ChangeLog files should be committed with an empty log message
>     (unless this is a real change in the ChangeLog file itself, not an
>     addition of log entries).

One other rule: the date label of the ChangeLog entry should reflect
the date on which the change was _committed_ (as opposed to the date
when the change was made in someone's local sandbox).  In other words,
the dates in the ChangeLog should be monotonically increasing from
bottom to top.  This is frequently an issue when installing someone
else's changes, but can also be a problem if you make a change in your
local sandbox, then wait for a while before committing it.

Re: CVS commits and logs

[Juanma Barranquero]

On 11/4/06, Eli Zaretskii <eliz@gnu.org> wrote:

> One other rule: the date label of the ChangeLog entry should reflect
> the date on which the change was _committed_ (as opposed to the date
> when the change was made in someone's local sandbox).

I've often wondered, and a few times I've even modified an entry's
date, when it was weeks or months off. It's nice to know that's the
rule.

> In other words,
> the dates in the ChangeLog should be monotonically increasing from
> bottom to top.

It's hard to have them monotonically increasing in a global world. An
Old World developer commits a change at 02:00 UTC, and minutes
afterwards someone from the New World commits a change with the
previous (from my POV) day's date...

Non-monotonic ChangeLog dates render the --from-date and --to-date
options of grep-changelog much less useful. I've even thinking of
patching it to give it a little leeway when searching the date
boundaries.

                    /L/e/k/t/u

Re: CVS commits and logs

[Eli Zaretskii]

> Date: Sat, 4 Nov 2006 13:53:41 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> > In other words,
> > the dates in the ChangeLog should be monotonically increasing from
> > bottom to top.
> 
> It's hard to have them monotonically increasing in a global world.

In practice, it's usually not a problem, but strictly speaking, the
date should be according to UTC, which solves the problem of
globalization.

Re: CVS commits and logs

[Juanma Barranquero]

On 11/4/06, Eli Zaretskii <eliz@gnu.org> wrote:

> In practice, it's usually not a problem

Not a problem, but I've seen it happen quite a few times.

> but strictly speaking, the
> date should be according to UTC, which solves the problem of
> globalization.

Shouldn't we add

;; add-log-time-zone-rule: t

to the Local Variables section of every ChangeLog file?

                    /L/e/k/t/u

Re: CVS commits and logs

[Eli Zaretskii]

> Date: Sat, 4 Nov 2006 14:44:54 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> Shouldn't we add
> 
> ;; add-log-time-zone-rule: t
> 
> to the Local Variables section of every ChangeLog file?

Yes, probably.  But it won't solve the case of late commits, which was
the original reason for what I wrote.

Re: CVS commits and logs

[Juanma Barranquero]

On 11/4/06, Eli Zaretskii <eliz@gnu.org> wrote:

> Yes, probably.

Well, there's the issue of being asked whether it is a safe local
variable (hmm... is `add-log-time-zone-rule' ever an unsafe local
variable?)

> But it won't solve the case of late commits, which was
> the original reason for what I wrote.

There's no Local Variables section in people's minds. At least, not
readily accessible.

-- 
                    /L/e/k/t/u

Re: CVS commits and logs

[Reiner Steib]

On Sat, Nov 04 2006, Juanma Barranquero wrote:

> Well, there's the issue of being asked whether it is a safe local
> variable (hmm... is `add-log-time-zone-rule' ever an unsafe local
> variable?)

Independent of whether or not we add `add-log-time-zone-rule' to Emacs
ChangeLog files, I think we should mark it as safe.

--8<---------------cut here---------------start------------->8---
--- add-log.el	26 Sep 2006 20:28:58 +0200	1.178
+++ add-log.el	04 Nov 2006 16:54:06 +0100	
@@ -293,6 +293,8 @@
 It takes the same format as the TZ argument of `set-time-zone-rule'.
 If nil, use local time.
 If t, use universal time.")
+(put 'add-log-time-zone-rule 'safe-local-variable
+     '(lambda (x) (or (booleanp x) (stringp x))))
 
 (defun add-log-iso8601-time-zone (&optional time)
   (let* ((utc-offset (or (car (current-time-zone time)) 0))
--8<---------------cut here---------------end--------------->8---

Okay to install?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: CVS commits and logs

[Juanma Barranquero]

On 11/4/06, Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> +(put 'add-log-time-zone-rule 'safe-local-variable
> +     '(lambda (x) (or (booleanp x) (stringp x))))

> Okay to install?

I like it.

                    /L/e/k/t/u

Re: CVS commits and logs

[Richard Stallman]

    Independent of whether or not we add `add-log-time-zone-rule' to Emacs
    ChangeLog files, I think we should mark it as safe.

Please do.

Re: CVS commits and logs

[Richard Stallman]

    ;; add-log-time-zone-rule: t

    to the Local Variables section of every ChangeLog file?

I think that we should do so.  Either that or we should make Change
Log mode do it.  But that might be annoying for projects whose
developers all live in more or less the same time zone.

    Well, there's the issue of being asked whether it is a safe local
    variable (hmm... is `add-log-time-zone-rule' ever an unsafe local
    variable?)

Its value is just copied into the TZ envvar.
I think that is always safe.

Re: CVS commits and logs

[Juanma Barranquero]

On 11/5/06, Richard Stallman <rms@gnu.org> wrote:

>     ;; add-log-time-zone-rule: t
>
>     to the Local Variables section of every ChangeLog file?
>
> I think that we should do so.

Reiner has committed the patch to consider `add-log-time-zone-rule' a
safe local variable.

It's OK now to add the above change to ChangeLog files?

                    /L/e/k/t/u

Re: CVS commits and logs

[Jason Rumney]

Eli Zaretskii wrote:
> In other words, the dates in the ChangeLog should be monotonically increasing from bottom to top.
Dates will not always monotonically increase even if people follow the 
rules, due to the fact that we are spread over several timezones.

Re: CVS commits and logs

[Eli Zaretskii]

> Date: Sat, 04 Nov 2006 22:28:22 +0000
> From: Jason Rumney <jasonr@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > In other words, the dates in the ChangeLog should be monotonically increasing from bottom to top.
> Dates will not always monotonically increase even if people follow the 
> rules, due to the fact that we are spread over several timezones.

UTC solves that problem.

Re: CVS commits and logs

[Richard Stallman]

      Exception: it is okay to
	commit several changes to a single ChangeLog file in one "cvs ci"
	command if those changes are related to the same feature/bugfix.

It's ok to commit unrelated items together in a ChangeLog file.

Aside from that, I agree with your rules.

    One other rule: the date label of the ChangeLog entry should reflect
    the date on which the change was _committed_ (as opposed to the date
    when the change was made in someone's local sandbox).

Yes.

      In other words,
    the dates in the ChangeLog should be monotonically increasing from
    bottom to top.

The change log entries should always be in order of most recently
committed first.  As Juanma points out, that doesn't always mean
the dates decrease.

Re: CVS commits and logs

[Bill Wohler]

Eli Zaretskii <eliz@gnu.org> writes:

>   . CVS log entries should be simply the ChangeLog entries with the
>     file name and the leading TABs stripped.

I agree if only one file is committed. However, if multiple files are
committed, I'd say leave the file names and strip the leading TABs.

>   . Each file should be committed separately, even if the changes are
>     related, and the CVS log entry should be for the changes in that
>     file only.  In particular, the modified files and the ChangeLog
>     file with the appropriate log entry should be committed separately
>     (thus the CVS log entries for ChangeLog files should never include
>     log entries for the modified files).  Exception: it is okay to
>     commit several changes to a single ChangeLog file in one "cvs ci"
>     command if those changes are related to the same feature/bugfix.

This isn't clear. In the first sentence you say, "even if the changes
are related" but the exception says--paraphrased--"except if the
change are related". Which is it?

I hope the latter since if one file depends on the changes of another,
you had better check both files in at the same time. It's too bad
we're not using Subversion, but by checking the files in with the same
commit, we can reduce the chance of breaking an update that occurs
before the other files are checked in. Second, by enumerating all of
the file names in a single log message, you can see easily which files
are affected by a given change.

>   . The ChangeLog files should be committed with an empty log message
>     (unless this is a real change in the ChangeLog file itself, not an
>     addition of log entries).

I check in the ChangeLog at the same time as I check in the file whose
change it describes. It's easy and the ChangeLog check-in is less
prone to be forgotten. It seems this is a common practice. Is there a
good reason for your rule?

Speaking of Subversion, if we switched to it, this discussion would go
away since we wouldn't even need a ChangeLog ;-). The "svn log"
command provides everything you need to know, and you can say "svn log
> ChangeLog" when you're creating a tarball for release.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

Re: CVS commits and logs

[Miles Bader]

Bill Wohler <wohler@newt.com> writes:
> I agree if only one file is committed. However, if multiple files are
> committed, I'd say leave the file names and strip the leading TABs.

And what about multiple _authors_?  Most of my commits are from
automatic merging, which more often than not involves multiple authors.
[I could just strip the author info from the commit messages, but it
seems silly to remove useful information.]

> I check in the ChangeLog at the same time as I check in the file whose
> change it describes. It's easy and the ChangeLog check-in is less
> prone to be forgotten. It seems this is a common practice. Is there a
> good reason for your rule?

Yes.  Indeed, I think it's far better practice to check in all changed
files (including ChangeLogs) with one CVS command, because it reduces
the chance that someone will see a partial commit (something I see
rather commonly actually -- some people seem to have a habit of
commiting the source files first, and then waiting a while before
committing the related ChangeLog changes (and it's not so uncommon that
they just forget to commit the ChangeLog entirely!).

Anyway, because of the nature of most of my commits, these rules seem
very hard to follow -- doing so would automatically would be difficult,
and the amount of extra work required to do so manually non-trivial -- I
see no choice other than to basically ignore them.

I can't see much justification for these specific rules anyway, other
than a vague sense that the commit logs are prettier.  [If there is some
better justification, please do tell.]

In fact, I think a rather different commit guideline might be more
useful from a technical point of view:  Commit all files in a single
"changeset" with a single "cvs ci" command, with a single log message.
This of course requires a commit-message format which can represent, at
the least, multiple file.

This particular guideline is useful because (1) it reduces the window of
opportunity for race conditions, and (2) the identical commit messages
are a _really_ useful hint to programs which scan the CVS repository
trying to group related commits into logical changesets; this is
typically done by gateways from CVS to a more modern source-code
management systems.

-Miles

-- 
Fast, small, soon; pick any 2.

Re: CVS commits and logs

[Richard Stallman]

I dislike multi-file CVS commits specifically because of the clutter
of having the entire change log entry in the log of each file.

    And what about multiple _authors_?  Most of my commits are from
    automatic merging, which more often than not involves multiple authors.

Is this all a matter of Gnus?  We could handle Gnus specially.

Re: CVS commits and logs

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> I dislike multi-file CVS commits specifically because of the clutter
> of having the entire change log entry in the log of each file.
>
>     And what about multiple _authors_?  Most of my commits are from
>     automatic merging, which more often than not involves multiple authors.
>
> Is this all a matter of Gnus?  We could handle Gnus specially.

Primarily Gnus, yes.

I basically wanted to point out that the guidelines being discussed,
while they definitely make prettier commit logs (I prefer that general
style too), are problematic for some uses.  [The fact that they make
simultaneous commit impossible is also a problem generally of course.]

-miles
-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

Re: CVS commits and logs

[Richard Stallman]

    > Is this all a matter of Gnus?  We could handle Gnus specially.

    Primarily Gnus, yes.

Could you explain why you do this in cases that are not in Gnus?

Re: CVS commits and logs

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     > Is this all a matter of Gnus?  We could handle Gnus specially.
>
>     Primarily Gnus, yes.
>
> Could you explain why you do this in cases that are not in Gnus?

I do this when I do merging.  Except for the Gnus 5.10 -> Emacs trunk
case, this merging doesn't occur to the trunk, but on branches (in many
of those cases I don't include changelog entries in the commit log
anyway, because it would make the commit log entries absurdly huge).

If you mostly care about the trunk, then it's safe to say that Gnus is
the only current case where I merge regularly to the trunk (you never
know what the future holds of course).

-Miles

-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: CVS commits and logs

[Richard Stallman]

    I do this when I do merging.  Except for the Gnus 5.10 -> Emacs trunk
    case, this merging doesn't occur to the trunk, but on branches (in many
    of those cases I don't include changelog entries in the commit log
    anyway, because it would make the commit log entries absurdly huge).

Does this include the unicode-2 branch?  Is it full of
multi-file commits where the trunk has single-file commits?

Re: CVS commits and logs

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> Does this include the unicode-2 branch?  Is it full of
> multi-file commits where the trunk has single-file commits?

Yes.  A single merge-commit to the unicode-2 branch represents many,
many changes on the trunk (hundreds of files, often multiple changes to
each file), so I don't include changelog info in the CVS log entry at
all.  The CVS log entry more or less says "merge from trunk of
changesets X-Y."

You'll find that this is _always_ how merging is done though, regardless
of who does it, because to actually track down the separate changelog
entries, package them up, and commit each file separately would be a lot
of work, very slow, and bloat the CVS logs, all for very little gain.

-Miles

-- 
Fast, small, soon; pick any 2.

Re: CVS commits and logs

[Bill Wohler]

Miles Bader <miles.bader@necel.com> wrote:

> Richard Stallman <rms@gnu.org> writes:
> > Does this include the unicode-2 branch?  Is it full of
> > multi-file commits where the trunk has single-file commits?
> 
> Yes.  A single merge-commit to the unicode-2 branch represents many,
> many changes on the trunk (hundreds of files, often multiple changes to
> each file), so I don't include changelog info in the CVS log entry at
> all.  The CVS log entry more or less says "merge from trunk of
> changesets X-Y."
> 
> You'll find that this is _always_ how merging is done though, regardless
> of who does it, because to actually track down the separate changelog
> entries, package them up, and commit each file separately would be a lot
> of work, very slow, and bloat the CVS logs, all for very little gain.

Not to mention, you would lose vital information about which versions
the merge came from. At least when merging manually, you need that
information to create the next merge. I usually use the verbatim cvs/svn
command in the log message which can be used to view the log messages of
the source versions by simply swapping "log" for "ci".

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

Re: CVS commits and logs

[Richard Stallman]

    Yes.  A single merge-commit to the unicode-2 branch represents many,
    many changes on the trunk (hundreds of files, often multiple changes to
    each file), so I don't include changelog info in the CVS log entry at
    all.  The CVS log entry more or less says "merge from trunk of
    changesets X-Y."

That seems to make the file's CVS log rather useless.  Or is the idea
that those changesets remain visible in the file's CVS log?  In that
case, they are a sort of indirection to the other change log items,
and that is ok.

Re: CVS commits and logs

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     Yes.  A single merge-commit to the unicode-2 branch represents many,
>     many changes on the trunk (hundreds of files, often multiple changes to
>     each file), so I don't include changelog info in the CVS log entry at
>     all.  The CVS log entry more or less says "merge from trunk of
>     changesets X-Y."
>
> That seems to make the file's CVS log rather useless.  Or is the idea
> that those changesets remain visible in the file's CVS log?  In that
> case, they are a sort of indirection to the other change log items,
> and that is ok.

Well, that sort of indirection is the idea, and it's currently
possible to find the source log entries, but not using CVS alone:  the
changeset information in the merge log refers to _arch_ changesets
(CVS doesn't even have the notion of a changeset), so one would have
to look in the arch repository to find the source log entries.

It would be possible to encode this information in CVS as well, by
making a unique CVS tag for each merge (the tag would be in the branch
merged _from_, so the log entry in the branch merged _to_ would say
basically merged from ..., see tag "trunk-merge-source-x-y-z").  That
would bloat the tag lists somewhat though, which might annoy people
(CVS spits out lists of tags at times, e.g. if you do "cvs log", and
if there are 10,000 almost identical tags ...).

Even with these tags, it would still be somewhat annoying for someone
to track down the exact original commit logs, but I don't think
there's really any practical alternative.

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: CVS commits and logs

[Andreas Schwab]

Miles Bader <miles@gnu.org> writes:

> (CVS spits out lists of tags at times, e.g. if you do "cvs log", and
> if there are 10,000 almost identical tags ...).

Adding "log -N" to .cvsrc avoids that.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: CVS commits and logs

[Miles Bader]

Andreas Schwab <schwab@suse.de> writes:
>> (CVS spits out lists of tags at times, e.g. if you do "cvs log", and
>> if there are 10,000 almost identical tags ...).
>
> Adding "log -N" to .cvsrc avoids that.

Yeah, but still it's somewhat annoying to have a bazillion tags.
E.g. sometimes I _want_ to see what tags there are, and having to deal
with filtering out a bunch of "uninteresting" tags is a bit of a bother.
Also they clog up tag menus in various CVS web interfaces.

-Miles

-- 
"Suppose we've chosen the wrong god. Every time we go to church we're
just making him madder and madder." -- Homer Simpson

Switching to Subversion (was: CVS commits and logs)

[Bill Wohler]

Miles Bader <miles@gnu.org> wrote:

> Andreas Schwab <schwab@suse.de> writes:
> >> (CVS spits out lists of tags at times, e.g. if you do "cvs log", and
> >> if there are 10,000 almost identical tags ...).
> >
> > Adding "log -N" to .cvsrc avoids that.
> 
> Yeah, but still it's somewhat annoying to have a bazillion tags.
> E.g. sometimes I _want_ to see what tags there are, and having to deal
> with filtering out a bunch of "uninteresting" tags is a bit of a bother.
> Also they clog up tag menus in various CVS web interfaces.

I agree with Miles. CVS' tag implementation encourages the use of as few
tags as possible. Subversion's implementation, however, allows you to
organize hierarchical layers of tags.

This is just one of many problems that would just go away if we switched
to Subversion. It would be a good time to switch after releasing 22 and
merging in the Unicode branch.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

Re: Switching to Subversion

[Romain Francoise]

Bill Wohler <wohler@newt.com> writes:

> This is just one of many problems that would just go away if we
> switched to Subversion. It would be a good time to switch after
> releasing 22 and merging in the Unicode branch.

Savannah doesn't offer Subversion hosting.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Switching to Subversion

[Bill Wohler]

Romain Francoise <romain@orebokech.com> writes:

> Bill Wohler <wohler@newt.com> writes:
>
>> This is just one of many problems that would just go away if we
>> switched to Subversion. It would be a good time to switch after
>> releasing 22 and merging in the Unicode branch.
>
> Savannah doesn't offer Subversion hosting.

Is that for a political reason or a technical reason? If the latter,
it can probably be overcome in a few hours by a couple of
knowledgeable folks.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

Re: Switching to Subversion

[Romain Francoise]

Bill Wohler <wohler@newt.com> writes:

> Is that for a political reason or a technical reason?

Lack of manpower, I think: https://savannah.gnu.org/maintenance/WhenSvN

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Switching to Subversion

[Richard Stallman]

Before considering use of subversion for Emacs I would have to use it
for something else, to see what it is like.

Re: Switching to Subversion

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> Before considering use of subversion for Emacs I would have to use
> it for something else, to see what it is like.

IIRC, TeXlive switched to it from a proprietary version control
system, and they experienced performance and/or bandwidth issues.  Now
TeXlive is a project with a _vast_ number of small files, probably
lots more than Emacs.

Maybe Karl Berry can report some of his experiences since he is, IIRC,
involved with TeXlive.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Switching to Subversion

[Juanma Barranquero]

On 11/12/06, David Kastrup <dak@gnu.org> wrote:

> IIRC, TeXlive switched to it from a proprietary version control
> system, and they experienced performance and/or bandwidth issues.

Performance issues could be related to having many files and so a big
working copy. Subversion 1.4.X includes a redesign of the WC's
metadata just to speed up these cases, so it'd be interesting to see
what release were they using.

We can always ask for a knowledgeable-if-not-totally-unbiased opinion
to Karl Fogel, who is (or was, a few months ago) reading this list :)

                    /L/e/k/t/u

Re: Switching to Subversion

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
>> Before considering use of subversion for Emacs I would have to use
>> it for something else, to see what it is like.
>
> IIRC, TeXlive switched to it from a proprietary version control
> system, and they experienced performance and/or bandwidth issues.  Now
> TeXlive is a project with a _vast_ number of small files, probably
> lots more than Emacs.

Another possibility is "git", which is what linux development uses
(it was originally written by Linus Torvalds) -- it's less mature, and
less simple-for-newbies than subversion (git has a much more obvious
"written by hackers" feel to it), but I think it uses a much better
model.  It has _excellent_ support for distributed development and
merging (it's more like arch in that sense, though very different in
others), two areas where subversion is usually considered weak.  Git is
also really, _really_ fast (by almost every measure --
cpu/disk/network), to an almost absurd degree, even on huge source trees
with lots of files (e.g., linux :-).

Git, like subversion, has also been increasingly adopted by FOSS
projects, e.g., Xorg now uses it.  The big downside to git currently
seem to be a somewhat sharp learning curve at the beginning.

[Note, I personally still use arch, but because it doesn't have much
development momentum behind it at this point, I'd be hesitant to
recommend it for a major project.]

-Miles

-- 
Do not taunt Happy Fun Ball.

Re: Switching to Subversion

[Juanma Barranquero]

On 11/12/06, Miles Bader <miles@gnu.org> wrote:

> It has _excellent_ support for distributed development and
> merging (it's more like arch in that sense, though very different in
> others), two areas where subversion is usually considered weak.

Subversion is weak in both areas, but both will be eventually
addressed. IIRC, there's already work being done in the issue of
merging, and the idea of distributed development (or "decentralized
version control") was talked about in a recent developer's meeting,
judging by the coments in the Subversives blog:

http://svn-dev.blogspot.com/2006/10/decentralized-version-control.html)

> The big downside to git currently
> seem to be a somewhat sharp learning curve at the beginning.

Does it run on Windows?

> [Note, I personally still use arch, but because it doesn't have much
> development momentum behind it at this point, I'd be hesitant to
> recommend it for a major project.]

And, on the other hand, that's one more reason for recommending SVN:
it is easy to use, stable, it's increasingly used in more and more
projects, and development is quite actively pursued. Honestly, I don't
know of another free SCM being, today, where SVN is. In a few years:
sure. But now, most of these systems (git probably excluded) seem too
much one-person efforts (or just-a-few-persons, to be fair).

                    /L/e/k/t/u

Re: Switching to Subversion

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
> Does it run on Windows?

Does anyone care?  :-/

Less flippantly:  almost certainly, using cygwin.  Which seems good
enough to me.  Given the large amount of momentum git has behind it, I
suppose the "native windows issue" is something that will be addressed
eventually, but it's not tremendously pressing for free software
developers -- installing cygwin is a no-brainer really.

Re: your other comments, see my reply to Sascha, and read Keithp's
essay.

-Miles

-- 
`Life is a boundless sea of bitterness'

Re: Switching to Subversion

[Juanma Barranquero]

On 11/13/06, Miles Bader <miles@gnu.org> wrote:

> Does anyone care?  :-/

Well... yes.

> Less flippantly:  almost certainly, using cygwin.  Which seems good
> enough to me.

Certainly it does *not* seem good enough to me! I don't want to be
forced to use that horrible kludge that is Cygwin.

> but it's not tremendously pressing for free software
> developers -- installing cygwin is a no-brainer really.

I think I've installed it (and deinstalled it) more times that I can
remember. No More.

                    /L/e/k/t/u

Re: Switching to Subversion

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
> Certainly it does *not* seem good enough to me! I don't want to be
> forced to use that horrible kludge that is Cygwin.

I dunno, I only use windows occasionally, but I installed it, and
programs written for just GNU/linux compiled without issues and ran.
My girlfriend (windows user, not a GNU hacker) installed it, found the
extra libraries she needed, and was configuring and compiling in
minutes.

That seems pretty useful.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Switching to Subversion

[stephen]

Miles Bader writes:

 > "Juanma Barranquero" <lekktu@gmail.com> writes:
 > > Does it run on Windows?

 > Less flippantly:  almost certainly, using cygwin.

I wouldn't be so sure until you've actually tried.  I went looking for
it recently (not exhaustively, but seriously) and all I could find
were threads from ca. Nov. 2005 about git not really working with
either Cygwin or MSYS.  NB: I was looking for a prepackaged version;
it may very well build and run for a hacker willing to work around
quirks.

Re: Switching to Subversion

[Bruce Stephens]

stephen@xemacs.org writes:

> Miles Bader writes:
>
>  > "Juanma Barranquero" <lekktu@gmail.com> writes:
>  > > Does it run on Windows?
>
>  > Less flippantly:  almost certainly, using cygwin.
>
> I wouldn't be so sure until you've actually tried.  I went looking
> for it recently (not exhaustively, but seriously) and all I could
> find were threads from ca. Nov. 2005 about git not really working
> with either Cygwin or MSYS.  NB: I was looking for a prepackaged
> version; it may very well build and run for a hacker willing to work
> around quirks.

I found the same information, I suspect.  However, now I look again I
find this <http://git.or.cz/gitwiki/WindowsInstall> which sounds more
encouraging.  (I guess if Mercurial really can incrementally import
and export git, then that might be an OK workaround, since I believe
Mercurial's better supported on Windows.)

Re: Switching to Subversion

[Juanma Barranquero]

On 11/13/06, Bruce Stephens <bruce.stephens@isode.com> wrote:

> However, now I look again I
> find this <http://git.or.cz/gitwiki/WindowsInstall> which sounds more
> encouraging.

A cygwin tool, a plugin for Eclipse (which is big big big, and dog
slow), and an Explorer extension based on cygwin... Excuse me if I
don't sound too excited.

                    /L/e/k/t/u

Re: Switching to Subversion

[Juanma Barranquero]

On 11/12/06, Richard Stallman <rms@gnu.org> wrote:

> Before considering use of subversion for Emacs I would have to use it
> for something else, to see what it is like.

Sounds reasonable. I think you'll find Subversion is designed to look
just like a better CVS. The command set is very similar.

There are quite a lot other good SCM programs out there (Arch,
Monotone, svk), but they are far less mature and, in my (limited)
tests, the user experience is very different. Arch filenames give me
headaches.

(Yes, I'm an una(bash|sham)ed Subversion proponent :)

                    /L/e/k/t/u

Re: Switching to Subversion

[Sascha Wilde]

"Juanma Barranquero" <lekktu@gmail.com> wrote:
> On 11/12/06, Richard Stallman <rms@gnu.org> wrote:
>
>> Before considering use of subversion for Emacs I would have to use it
>> for something else, to see what it is like.
>
> Sounds reasonable. I think you'll find Subversion is designed to look
> just like a better CVS. The command set is very similar.

> There are quite a lot other good SCM programs out there (Arch,
> Monotone, svk), but they are far less mature and, in my (limited)
> tests, the user experience is very different. Arch filenames give me
> headaches.

I have to plug mercurial[0] in this thread.  It's a distributed SCM
written in python, which has a ui which is very similar to cvs, too
(at least for all operation where this is possible).  

In addition to most of svn's advantages it's a real distributed SCM
and allows for comfortable offline use.  And its lightweight, too.

It is relatively new, but very stable and successfully used for big
projects (prominent examples are XEN and OpenSolaris, which both chose
it as there primary SCM).

For those interested: as announced before I'm maintaining a converted
mirror of the Emacs CVS and my own development version of Emacs here:
http://hg.intevation.de/emacs and http://hg.intevation.de/emacs/wilde

One of the core developers of mercurial is a friend and colleague of
mine, so I might well be biased, but I would really love to see
mercurial to be used for emacs development.  :-)

Btw. there is no support for mercurial in Emacs yet, but DVC[1]
includes some very usable support...

cheers
sascha

[0] http://hg.intevation.de/
[1] http://www.xsteve.at/prg/emacs_dvc/
-- 
Sascha Wilde

"There is no reason why anyone would want a computer in their home"
Ken Olson, DEC, 1977

Re: Switching to Subversion

[Miles Bader]

Sascha Wilde <wilde@sha-bang.de> writes:
> I have to plug mercurial[0] in this thread.  It's a distributed SCM
> written in python, which has a ui which is very similar to cvs, too
> (at least for all operation where this is possible).  

Here's Keith Packard's (of X11 fame) rather well-argued take on the
issue:

   http://keithp.com/blog/Repository_Formats_Matter.html

He provides pretty good arguments _against_ subversion, but also
addresses mercurial vs. git a bit (mercurial is in some sense a riff on
git, btw).

Here's the final few paragraphs:

   We were not particularly interested in the kind of massive distributed
   development model seen in the kernel, but the ability to work off-line
   (some of us spend an inordinate amount of time on airplanes) and still
   provide fine-grained detail about our work makes a purely central model
   less than ideal. Plus, the powerful merge operations that Git provides
   for the kernel developers are still useful in our environment, if not as
   heavily exercised.

   I know Git suffers from its association with the wild and wooly kernel
   developers, but they've pushed this tool to the limits and it continues
   to shine. Right now, there's nothing even close in performance,
   reliability and functionality. Yes, the user interface continues to need
   improvements. Small incremental changes have been made which make the
   tools more consistent, and I hope to see those discussions
   continue. Mostly, the developers respond to cogent requests (with code)
   from the user community; if you find the UI intolerable, fix it. But,
   know that while the UI improves, the underlying repository remains fast,
   stable and reliable.

   And yes, Havoc, anyone seriously entertaining moving to SVN should have
   their heads examined.

-miles
-- 
`Life is a boundless sea of bitterness'

Re: Switching to Subversion

[Juanma Barranquero]

On 11/13/06, Miles Bader <miles@gnu.org> wrote:

> He provides pretty good arguments _against_ subversion

Based on false statements, like this one:

"The old Berkeley DB-based backend has been deprecated as unstable and
subject to corruption [..."

FSFS is the default, but the BDB backend was never "deprecated as
unstable". And, in the ChangeLog of the latest release, there's this
bit of information:

  A common problem with previous versions of Subversion is that
  crashed server processes could leave BerkeleyDB-based
  repositories in an unusable "wedged" state, requiring
  administrators to manually intervene and bring back online.
  (Note: this is not due to bugs in BerkeleyDB, but due to the
  unorthodox way in which Subversion uses it!)

  Subversion 1.4 can now be compiled against BerkeleyDB 4.4,
  which has a new "auto-recovery" feature. If a Subversion server
  process crashes and leaves the repository in an inconsistent
  state, the next process which attempts to access the repository
  will notice the problem, grab exclusive control of the
  repository, and automatically recover it. In theory (and in our
  testing), this new feature makes BerkeleyDB-based repositories
  just as wedge-proof as FSFS repositories.

>    And yes, Havoc, anyone seriously entertaining moving to SVN should have
>    their heads examined.

Ah, yes, a good technical argument.

                    /L/e/k/t/u

Re: Switching to Subversion

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
> Based on false statements, like this one:
>
> "The old Berkeley DB-based backend has been deprecated as unstable and
> subject to corruption [..."
>
> FSFS is the default, but the BDB backend was never "deprecated as
> unstable".

I have no idea, but read his arguments Re: repository formats.

>>    And yes, Havoc, anyone seriously entertaining moving to SVN should have
>>    their heads examined.
>
> Ah, yes, a good technical argument.

Keithp not some random flamer, but this is from his blog, so he's
probably a bit looser than usual.  The meat of the essay is obviously in
the preceding text.

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: Switching to Subversion

[Juanma Barranquero]

On 11/13/06, Miles Bader <miles@gnu.org> wrote:

> I have no idea, but read his arguments Re: repository formats.

I've read it. But you cannot seriously discuss Subversion by misstating BDB.

                    /L/e/k/t/u

Re: Switching to Subversion

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
>> I have no idea, but read his arguments Re: repository formats.
>
> I've read it. But you cannot seriously discuss Subversion by misstating BDB.

The meaning of "deprecated" is subject to interpretation (for all I know
he was referring to de-facto deprecation and common understanding, not
"official" deprecation).  In any case, whether or not he's correct about
subversion's official stance on the issue, that does not affect the bulk
of his arguments, which are based on rather fundamental issues.

[If you are not familiar with git, I would recommend researching it,
it's a _very_ innovative system.]

-Miles

-- 
"Suppose He doesn't give a shit?  Suppose there is a God but He
just doesn't give a shit?"  [George Carlin]

Re: Switching to Subversion

[Juanma Barranquero]

On 11/13/06, Miles Bader <miles@gnu.org> wrote:

> subversion's official stance on the issue, that does not affect the bulk
> of his arguments, which are based on rather fundamental issues.

For some definition of "rather fundamental issues." He mentions a good
feature of git:

"Files containing object data are never modified. Once written, every
file is read-only from that point forward."

but that's exactly what FSFS does. Then tries to make the off-line
compression of git pass as something good (which surely is, in *his*
setup, but not generally). Then rejects BDB off-hand (perhaps because
it would score better against some of his arguments), and considers
FSFS flawed because "[it] places one file per revision in a single
directory; a test import of Mozilla generated hundreds of thousands of
files in this directory, causing performance to plummet as more
revisions were imported". But having these files in a single directory
is not a *fundamental* property of FSFS; it can be easily changed, and
in fact there's been already talk of doing it. It would be trivial.

He continues: "I'm not sure what each file contains, but it seems like
revisions are written as deltas to an existing revision, making damage
to one file propagate down through generations", not having taken the
time to know how the revisions are stored; the complete text is saved
every N deltas (for a small N), so any possible corruption would not
be propagated. Funnily, then adds: "Lack of strong error detection
means such errors will be undetected by the repository. CVS used to
suffer badly from this when NFS would randomly zero out blocks of
files", which tries to suggest that SVN lacks strong error detection,
which he didn't demonstrate. Then he talks about the size of one
repository imported from CVS; but this is not the normal growing
pattern of a SVN repository (CVS has lots more commits because they
are not atomic). And he shows that he doesn't really know about
Subversion, because if he were, he could've talked of the size of
Subversion *working copies*, which can be two or more times the size
of the checked out files and have really generated some complains.

All in all, not many compelling arguments here, and quite a lot of
uninformed misrepresentations.

> [If you are not familiar with git, I would recommend researching it,
> it's a _very_ innovative system.]

I've never used it, but I've read some articles (and a few threads by
Linus Torvalds) about it.

                    /L/e/k/t/u

Re: Switching to Subversion

[Stefan Monnier]

> revisions were imported". But having these files in a single directory
> is not a *fundamental* property of FSFS; it can be easily changed, and
> in fact there's been already talk of doing it. It would be trivial.

I don't really want to get into this thread, but I'm interested in the
subject, so I'll just comment here.  I don't really like Subversion and
would rather use some other tool for the following reason:

- The above comment is something I've often heard about Subversion: "this
  or that internal feature is not prevented by SVN, it's just not supported
  yet, but someone's already working on it".  In contrast the other
  competitors tend to suffer from a underdevelopped UI rather than
  underdevelopped internals.  The support for merging is an obvious case
  in point.  Basically Subversion's been UI-driven, with fundamental
  features retrofitted afterwards.  That is a design methodology which
  doesn't always result in the cleanest and most robust result.

- Subversion has had more hours (and manhours) devoted to it than the sum of
  its competitors, yet it still lacks the most commonly needed tool
  (besides what CVS already offers): merge support.

- Subversion is a big and heavy piece of software, which I'm not very eager
  to have to rely on.

- Subversion is strongly associated in my mind with Open Source as opposed
  to Free Software.

So I'd rather use Arch, DaRCS, Mercurial, GIT, you name it.
Now, I'm sure the above has some misconceptions, because I haven't looked at
Subversion in a long time (I was following it fairly closely at its
beginning, before alternatives like Arch started to appear), but I believe
that the core ideas are still valid.


        Stefan

Re: Switching to Subversion

[Juanma Barranquero]

On 11/13/06, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Basically Subversion's been UI-driven, with fundamental
> features retrofitted afterwards.  That is a design methodology which
> doesn't always result in the cleanest and most robust result.

In my opinion (and I'm just a lurker on Subversion), that's not
entirely true. On one hand, yes, it was a  bit UI-driven because its
stated goal was to be "a better CVS". But on the other hand, some
things are just the result of decisions that seemed good at the time:
for example, not having true renames, or using branches for tagging.

> - Subversion has had more hours (and manhours) devoted to it than the sum of
>   its competitors, yet it still lacks the most commonly needed tool
>   (besides what CVS already offers): merge support.

Doing it right is hard, and probably couldn't be really made in a
back-compatible way. I'd expect that for 2.0. And, to be fair, that
time has been spent in other ways: alternative backends, three
repository access methods, WebDAV/DeltaV, good bindings for
third-party tools (look at SVK :), localization, *excellent*
documentation, and it is generally rock-solid. As I've said several
times, what SVN has is much more maturity; that's where the manhours
have been spent.

> - Subversion is a big and heavy piece of software, which I'm not very eager
>   to have to rely on.

Well, I prefer that to requiring Python or Perl or Haskell (which I
love) or whatnot. And certainly SCMs whose interface is made of
scripts don't strike me as very serious (call me prejudiced).

> So I'd rather use Arch, DaRCS, Mercurial, GIT, you name it.

I don't have anything against other tools, of course, if they have
native implementations in Windows and the interface is reasonably fast
(assuming the underlying design is sound :)

                    /L/e/k/t/u

Re: Switching to Subversion

[Juanma Barranquero]

On 11/13/06, Juanma Barranquero <lekktu@gmail.com> wrote:

> or using branches for tagging.

"using copies for branches and tags", I meant.

                    /L/e/k/t/u

Re: Switching to Subversion

[Stefan Monnier]

>> - Subversion has had more hours (and manhours) devoted to it than the sum of
>> its competitors, yet it still lacks the most commonly needed tool
>> (besides what CVS already offers): merge support.

> Doing it right is hard, and probably couldn't be really made in
> a back-compatible way. I'd expect that for 2.0. And, to be fair, that time
> has been spent in other ways: alternative backends, three repository
> access methods, WebDAV/DeltaV, good bindings for third-party tools (look
> at SVK :), localization, *excellent* documentation, and it is generally
> rock-solid.

All I really need from a successor to CVS:
- one backend that works well enough.
- same access methods as CVS (i.e. ssh/sftp and anonymous).
- good support for batch-processing (neat bindings via dlls is of no use for
  Emacs).  Localization can even get in the way here.
- support for merge.
- support for file rename.

The first 3 are what CVS already provides.  Svn only added the last point
and forgot the penultimate (even though it's a lot more important in my
experience).

Yes, SVN's doc is good.  But I can't help feel very uncomfortable with
a project that took so much time on side things and buzzwords and forgot the
core "branch merge" operation.

> As I've said several times, what SVN has is much more maturity; that's
> where the manhours have been spent.

Not quite true: manhours have also been spent in large part on the lack of
a clean and simple basic design.  Simplicity has never really been serious
design considerations (at least not at the beginning, when it mattered).
The contrast with something like DaRCS, Arch, ..., is truly striking.

>> - Subversion is a big and heavy piece of software, which I'm not very eager
>> to have to rely on.
> Well, I prefer that to requiring Python or Perl or Haskell (which I
> love) or whatnot.

[ I really don't want to go there. ]
Haskell (and Python and Perl to a lesser degree) are much more reliable
languages than C, with whole classes of bugs (some of which are among the
most notorious security holes) ruled out by the language itself.

> I don't have anything against other tools, of course, if they have
> native implementations in Windows and the interface is reasonably fast
> (assuming the underlying design is sound :)

Yes, Arch is out, sadly.  It doesn't support Windows well enough, and its
speed is terrible under Mac OS X (apparently because HFS+ handles hardlinks
pessimally).


        Stefan

Re: Switching to Subversion

[Bill Wohler]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> - Subversion has had more hours (and manhours) devoted to it than the sum of
>>> its competitors, yet it still lacks the most commonly needed tool
>>> (besides what CVS already offers): merge support.
>
>> Doing it right is hard, and probably couldn't be really made in
>> a back-compatible way. I'd expect that for 2.0. And, to be fair, that time
>> has been spent in other ways: alternative backends, three repository
>> access methods, WebDAV/DeltaV, good bindings for third-party tools (look
>> at SVK :), localization, *excellent* documentation, and it is generally
>> rock-solid.
>
> All I really need from a successor to CVS:
> - one backend that works well enough.
> - same access methods as CVS (i.e. ssh/sftp and anonymous).
> - good support for batch-processing (neat bindings via dlls is of no use for
>   Emacs).  Localization can even get in the way here.
> - support for merge.
> - support for file rename.
>
> The first 3 are what CVS already provides.  Svn only added the last point
> and forgot the penultimate (even though it's a lot more important in my
> experience).

Definitely, and that's why the Subversion team is working on it.

  http://subversion.tigris.org/merge-tracking/

Eventually, we'll have that too. In the meantime, while merging is the
same as CVS, at least branching is *much* easier and cleaner.

Subversion has an Emacs interface (both vc-svn.el and psvn.el), native
Windows interface (Tortoise), and an Eclipse interface. The only thing
it is missing is Savannah support.

If you have Subversion experience and a little time, please help get
it running at Savannah:

  https://savannah.gnu.org/maintenance/WhenSvN

Once it is fully supported there, then we can revisit this issue. By
then, hopefully, Richard will have had the opportunity to play with
it. Until then, Richard, the manual is at:

  http://svnbook.red-bean.com/

And you can play, read-only, with the Subversion repository for the MH
book by checking it out with:

  svn co https://svn.sourceforge.net/svnroot/rand-mh/book/trunk mh-book

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

Re: Switching to Subversion

[Stefan Monnier]

>> The first 3 are what CVS already provides.  Svn only added the last point
>> and forgot the penultimate (even though it's a lot more important in my
>> experience).
> Definitely, and that's why the Subversion team is working on it.

Again: when will it be available?  How many KLOCs wand man-years will be
necessary to get this into Subversion, when it has been one of the early
features of pretty much every other competitor?

>   http://subversion.tigris.org/merge-tracking/

Compare the complexity of the above design document to the simplicity of the
solutions used in DaRCS and Arch (for example).  It makes you cry.


        Stefan

Re: Switching to Subversion

[Jari Aalto]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Yes, Arch is out, sadly.  It doesn't support Windows well enough, and its
> speed is terrible under Mac OS X (apparently because HFS+ handles hardlinks
> pessimally).

I would suggest bzr. I has very lively and responsive group of
developers. They spend great deal of their time in  discussing various
aspecta nd users' preferences. 

- It support CVS stulyl "star topology" 
- Support distributed branch development
- Has very good merge support
- Is Windoes/*nix agnostic; written in Python
- Includes Emacs back-ends (DVC, bzr-vc.el, etc.)

For more information:

  http://doc.bazaar-ng.org/

Gis ot really not suitable, since it's collection of "scripts" ans has
no structure for long term development. It does not support native
win32 due to being sh-based in general (although some are implemented
in C). Git also has unique idea of "all or nothing" where the
repositories are completely identical to each othe rincluding all of
the histiry in every machince. This may work for kernel development
model, but fo generic SW development, it is not suitable. 

People are used to developep "a feature" that is merged into the
mainline. Git has no such concept. It treats all repositories equal.

Mercurical and Bzr would better support CVS style and and distributed
style development simultaneously. 

Git is purely distributes and doe snot support start-like-development.

Jari

Re: Switching to Subversion

[Miles Bader]

Jari Aalto <jari.aalto@cante.net> writes:
> Mercurical and Bzr would better support CVS style and and distributed
> style development simultaneously. 
>
> Git is purely distributes and doe snot support start-like-development.

Thanks for illustrating that you haven't the faintest idea what you're
talking about Jari.

-Miles

-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: Switching to Subversion

[Jari Aalto]

Miles Bader <miles.bader@necel.com> writes:

> Jari Aalto <jari.aalto@cante.net> writes:
> > Mercurical and Bzr would better support CVS style and and distributed
> > style development simultaneously. 
> >
> > Git is purely distributes and doe snot support start-like-development.
> 
> Thanks for illustrating that you haven't the faintest idea what you're
> talking about Jari.

The git is purely distributed and was never designed to have
star-like-development model support (like SVN/CVS). 

This does not mean that it can't emulate that somewhat, but the
concept how it achieves it is quite different. there is no actual
"master" repository" except in conceptual level. The "central"
repository can appear only when group of developers agree that some
location is considered special. But from technical point of view all
git's local repositories are equal.

So, there is no workflow of centralized model like:

- Sources and history is THERE
- my working copy is HERE

present in git's idea. This is natural because git is fully
decentralized with gobal revids.

Jari

Re: Switching to Subversion

[Sascha Wilde]

Miles Bader <miles@gnu.org> wrote:

> Sascha Wilde <wilde@sha-bang.de> writes:
>> I have to plug mercurial[0] in this thread.  It's a distributed SCM
>> written in python, which has a ui which is very similar to cvs, too
>> (at least for all operation where this is possible).  
>
> Here's Keith Packard's (of X11 fame) rather well-argued take on the
> issue:
>
>    http://keithp.com/blog/Repository_Formats_Matter.html
>
> He provides pretty good arguments _against_ subversion, but also
> addresses mercurial vs. git a bit (mercurial is in some sense a riff on
> git, btw).

While I'm not to happy with the kind of argumentation he uses against
SVN, I do strongly agree with his point that offline capabilities are
a great win.

One big obstacle with git (which he mentions, too) is the
user interface.  With a project like Emacs I think its rather
essential, that the SCM is easy to use for developers, and most
developers are used to CVS.  Mercurial is designed to be very
approachable to people knowing CVS.

Another interesting point is performance, experience shows that
mercurial is not slower than git, in fact, there are certain
situations where mercurial is way faster.  And when it comes to usage
of resources (RAM, disk space) mercurial is (sometimes _much_) more
efficient, too. -- Sorry for sounding a bit like a commercial, but I
was quite skeptical my self until Thomas (I CCed him) convinced me to
actually try it, and now I'm really a fan...  ;-)

cheers
sascha
-- 
Sascha Wilde : VI is to EMACS as masturbation is to making love:
             : effective and always available but probably not your
             : first choice...

Re: Switching to Subversion

[David Kastrup]

Sascha Wilde <wilde@sha-bang.de> writes:

[...]

> One big obstacle with git (which he mentions, too) is the
> user interface.  With a project like Emacs I think its rather
> essential, that the SCM is easy to use for developers, and most
> developers are used to CVS.  Mercurial is designed to be very
> approachable to people knowing CVS.

In my opinion, any SCM system that is not fully supported by a stock
Emacs 22 on all major operating systems where Emacs runs on is not
acceptable for managing Emacs 23.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Switching to Subversion

[Juanma Barranquero]

On 11/13/06, David Kastrup <dak@gnu.org> wrote:

> In my opinion, any SCM system that is not fully supported by a stock
> Emacs 22 on all major operating systems where Emacs runs on is not
> acceptable for managing Emacs 23.

 C:\emacs\HEAD> dir lisp\vc-*.el

  Volume in drive C is unlabeled      Serial number is 0836:9fa9
  Directory of  C:\emacs\HEAD\lisp\vc-*.el

 07/02/2006   9:57          15.633  vc-arch.el
 07/02/2006   9:57          38.831  vc-cvs.el
 13/10/2006   8:53          38.428  vc-hooks.el
 07/02/2006   9:57          23.011  vc-mcvs.el
 07/02/2006   9:57          54.916  vc-rcs.el
 07/02/2006   9:57          14.726  vc-sccs.el
 09/11/2006  11:08          21.955  vc-svn.el

:)

                    /L/e/k/t/u

Re: Switching to Subversion

[Sascha Wilde]

David Kastrup <dak@gnu.org> wrote:

> Sascha Wilde <wilde@sha-bang.de> writes:
>
> [...]
>
>> One big obstacle with git (which he mentions, too) is the
>> user interface.  With a project like Emacs I think its rather
>> essential, that the SCM is easy to use for developers, and most
>> developers are used to CVS.  Mercurial is designed to be very
>> approachable to people knowing CVS.
>
> In my opinion, any SCM system that is not fully supported by a stock
> Emacs 22 on all major operating systems where Emacs runs on is not
> acceptable for managing Emacs 23.

There are some Emacs modes supporting mercurial available: DVC (which
I use) and mercurial.el, which comes with mercurial, for example.  (I
think there were some more, but I wasn't able to find them right now)

I'm absolutely positive that the developers of either would be willing
to sign papers, and as these are self contained modes, I think it
could even be an option to integrated them at this point of the
release process.  

But on the other hand: Emacs Developers will be using the development
version anyway, so integrating mercurial support shortly after the
release should be sufficient.

cheers
sascha
-- 
Sascha Wilde
God put me on earth to accomplish a certain number of things.
Right now I am so far behind I will never die.
                       -- Bill Waterson, Calvin and Hobbes

Re: Switching to Subversion

[David Kastrup]

Sascha Wilde <wilde@sha-bang.de> writes:

> David Kastrup <dak@gnu.org> wrote:
>
>> In my opinion, any SCM system that is not fully supported by a
>> stock Emacs 22 on all major operating systems where Emacs runs on
>> is not acceptable for managing Emacs 23.
>
> But on the other hand: Emacs Developers will be using the
> development version anyway, so integrating mercurial support shortly
> after the release should be sufficient.

Disagree.  Shortly after the release, development versions can be
expected to be hosed temporarily, and the only Emacs version one can
depend on to work reliably is the last released one.

If you can't work the SCM from a _stable_ version of Emacs, it is a
mess to get back on track.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Switching to Subversion

[dhruva]

Hi,
 Adding to an already long chain are my experiences (as I was involved
in selecting a SCM for the project).

On the work/professional front, I am working on porting Samba to
OpenVMS (in HP). We found a need to have a distributed SCM (as the
native SCM known as CMS had some limitations).

- Since Samba project uses SVN (subversion), I thought it was best for
us to use SVN. I was willing to run the server on GNU/Linux box and
have clients on VMS (on which we develop). We did not find the
clients.
- I was then inclined in using bazaar which is implemented in PYTHON.
Since PYTHON is quite well ported, I assumed the clients would run
seamlessly on VMS. The snag was that the current bazaar-ng requires
PYTHON 2.5+ (only 2.4 is ported on VMS)
- CVS was was the only option left. The client was available on ALPHA
VMS, with miminal changes to the build scripts, I was able to get it
on IA64 (Itanium) VMS.

Ever since, we have being using CVS. I am waiting for getting PYTHON
2.5 on VMS to be able to start using bazaar-ng. IMO, the idea of
client being developed in a language that is interpreted or works on a
virtual machine is ideal. The SCM developers need not worry on
portability and can concentrate on adding the SCM features!

-dk

-- 
dhruva (dk)
Contents reflect my personal views only!

Re: Switching to Subversion

[Thomas Arendsen Hein]

* dhruva <dhruvakm@gmail.com> [20061113 10:54]:
> - I was then inclined in using bazaar which is implemented in PYTHON.
> Since PYTHON is quite well ported, I assumed the clients would run
> seamlessly on VMS. The snag was that the current bazaar-ng requires
> PYTHON 2.5+ (only 2.4 is ported on VMS)
> - CVS was was the only option left. The client was available on ALPHA
> VMS, with miminal changes to the build scripts, I was able to get it
> on IA64 (Itanium) VMS.
> 
> Ever since, we have being using CVS. I am waiting for getting PYTHON
> 2.5 on VMS to be able to start using bazaar-ng. IMO, the idea of
> client being developed in a language that is interpreted or works on a
> virtual machine is ideal. The SCM developers need not worry on
> portability and can concentrate on adding the SCM features!

Mercurial runs fine on Python 2.3. It uses very few C extensions,
but they have been tested on many architectures and platforms.

Thomas

-- 
Email: thomas@intevation.de
http://intevation.de/~thomas/

Re: Switching to Subversion

[Jari Aalto]

dhruva <dhruvakm@gmail.com> writes:

> Hi,
>  Adding to an already long chain are my experiences (as I was involved
> in selecting a SCM for the project).
> 
> - I was then inclined in using bazaar which is implemented in PYTHON.
> Since PYTHON is quite well ported, I assumed the clients would run
> seamlessly on VMS. The snag was that the current bazaar-ng requires
> PYTHON 2.5+ (only 2.4 is ported on VMS)

This must be some kind of mixup. Bzr doe snore require python 2.5+.
It runs fine on standard python 2.4

    $ python -V
    Python 2.4.2

    $ bzr --version
    Bazaar (bzr) 0.10.0
    Using python interpreter: /usr/local/bin/python
    Using python standard library: /usr/local/lib/python2.4

Neither should 0.12 or forthcoming 0.13 require python 2.5.
It's the other way round: there are changes in bzr to make it 
portable to 2.5.

Jari

Re: Switching to Subversion

[Sascha Wilde]

David Kastrup <dak@gnu.org> wrote:

> Sascha Wilde <wilde@sha-bang.de> writes:
>
>> David Kastrup <dak@gnu.org> wrote:
>>
>>> In my opinion, any SCM system that is not fully supported by a
>>> stock Emacs 22 on all major operating systems where Emacs runs on
>>> is not acceptable for managing Emacs 23.
>>
>> But on the other hand: Emacs Developers will be using the
>> development version anyway, so integrating mercurial support shortly
>> after the release should be sufficient.
>
> Disagree.  Shortly after the release, development versions can be
> expected to be hosed temporarily, and the only Emacs version one can
> depend on to work reliably is the last released one.
>
> If you can't work the SCM from a _stable_ version of Emacs, it is a
> mess to get back on track.

Mercurial (respectively the supporting modes) does work with Emacs 22,
it's just that they aren't part of the stock distribution yet.  If
it is really essential that the SCM support for a potential new system
is part of the current release (which I doubt), we should try to get
it in before the release.

The most important point is: we shouldn't base a decision for or
against a new SCM on that question, especially not when there _is_
support for Emacs available and the supporting modes are just not part
of Emacs yet.

In fact, at this point of time there is no support for most free
distributed SCMs (git, bazar, bazar ng, darcs, monotone, mercurial
...) in stock Emacs, it would be a big loss if this would be a reason
to rule out all of them.

cheers
sascha
-- 
"Anyone who slaps a 'this page is best viewed with Browser X' label on a Web 
page appears to be yearning for the bad old days, before the Web, when you had 
very little chance of reading a document written on another computer, another 
word processor, or another network." -- Tim Berners-Lee, July 1996

Re: Switching to Subversion

[Juanma Barranquero]

On 11/13/06, Sascha Wilde <wilde@sha-bang.de> wrote:

> In fact, at this point of time there is no support for most free
> distributed SCMs (git, bazar, bazar ng, darcs, monotone, mercurial
> ...) in stock Emacs, it would be a big loss if this would be a reason
> to rule out all of them.

Lack of support in Savannah should be an issue, though.

                    /L/e/k/t/u

Re: Switching to Subversion

[Han-Wen Nienhuys]

Juanma Barranquero escreveu:
>> In fact, at this point of time there is no support for most free
>> distributed SCMs (git, bazar, bazar ng, darcs, monotone, mercurial
>> ...) in stock Emacs, it would be a big loss if this would be a reason
>> to rule out all of them.
> 
> Lack of support in Savannah should be an issue, though.

See http://git.sv.gnu.org/gitweb.

As for personal experiences, we tried some things for LilyPond, and I 
have the following to add

  - I concur with Juliusz that using centralized VC today is a bad move

  - GIT: steep learning curve, but it also has a clear model that makes 
it very predictable to determine whether something is possible or not. 
There is also a lot of tool support.

  - darcs: a clear model from theoretical point of view, but we could 
never get the hang of the user interface, syncing was too slow for a 
serious project.


-- 
  Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: Switching to Subversion

[David Kastrup]

Sascha Wilde <wilde@sha-bang.de> writes:

> David Kastrup <dak@gnu.org> wrote:
>
>> Sascha Wilde <wilde@sha-bang.de> writes:
>>
>>> But on the other hand: Emacs Developers will be using the
>>> development version anyway, so integrating mercurial support shortly
>>> after the release should be sufficient.
>>
>> Disagree.  Shortly after the release, development versions can be
>> expected to be hosed temporarily, and the only Emacs version one
>> can depend on to work reliably is the last released one.
>>
>> If you can't work the SCM from a _stable_ version of Emacs, it is a
>> mess to get back on track.

[...]

> The most important point is: we shouldn't base a decision for or
> against a new SCM on that question, especially not when there _is_
> support for Emacs available and the supporting modes are just not
> part of Emacs yet.

Disagree.

> In fact, at this point of time there is no support for most free
> distributed SCMs (git, bazar, bazar ng, darcs, monotone, mercurial
> ...) in stock Emacs, it would be a big loss if this would be a
> reason to rule out all of them.

Disagree.  We need stability, dependability and a proven track record
for interaction with Emacs.  We don't have the manpower to fix a bad
choice.  A lack of a well-established feasibility for large-scale
projects in combination with Emacs and a number of operating systems
is, in my opinion, a definite reason to rule out any system.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Switching to Subversion

[Sascha Wilde]

David Kastrup <dak@gnu.org> wrote:

> Sascha Wilde <wilde@sha-bang.de> writes:
[...]
>> In fact, at this point of time there is no support for most free
>> distributed SCMs (git, bazar, bazar ng, darcs, monotone, mercurial
>> ...) in stock Emacs, it would be a big loss if this would be a
>> reason to rule out all of them.
>
> Disagree.  We need stability, dependability 

Ack -- not the disagree of cause... ;-)

> and a proven track record
> for interaction with Emacs. 

I don't see how this would be any more the case for SVN than
mercurial.  In fact, I don't see how this could be the case for _any_
other SCM than CVS, which would imply not to change the main SCM --
which IMO _is_ a serious option.

> We don't have the manpower to fix a bad choice. 

Are you talking about the SCM or about the Emacs support for the SCM
here?  In the later case I don't fully agree, most parts of Emacs get
constantly improved mainly because people actually (have to) use them.

> A lack of a
> well-established feasibility for large-scale projects

I would say, this is the case for mercurial, not only by personal
experience, but from the references, too:
http://www.selenic.com/mercurial/wiki/index.cgi/ProjectsUsingMercurial

> in combination
> with Emacs

as said before, I don't see how to prove this point, apart from emacs
there are very few projects where the frontend tools used by the
developers are well known...

I do use mercurial together with DVC, and think that it is sufficient
usable, there might be glitches, but even PCVS has its glitches,
doesn't it?

> and a number of operating systems is, in my opinion, a
> definite reason to rule out any system.

Mercurial is written in python and well tested on many platforms.  I
used it my self on GNU/Linux, NetBSD, Solaris, HP-UX and AIX -- and
Windows is supported, too.

cheers
sascha
-- 
Sascha Wilde

A conclusion is simply the place where someone got tired of thinking.

Re: Switching to Subversion

[Juanma Barranquero]

On 11/13/06, Sascha Wilde <wilde@sha-bang.de> wrote:

> Are you talking about the SCM or about the Emacs support for the SCM
> here?  In the later case I don't fully agree, most parts of Emacs get
> constantly improved mainly because people actually (have to) use them.

On this point: we're not here in the business of improving either the
SCM tool or the tool's interaction with Emacs (though that is
desirable, of course). We're in the business of improving Emacs. The
tool should be as transparent as possible. We don't want to spend our
time hammering the SCM into allowing us to work on Emacs.

(Not that this would be the case of Mercurial; I don't know. I'm
talking about general principles.)

                    /L/e/k/t/u

Re: Switching to Subversion

[Miles Bader]

Sascha Wilde <wilde@sha-bang.de> writes:
> Another interesting point is performance, experience shows that
> mercurial is not slower than git, in fact, there are certain
> situations where mercurial is way faster.  And when it comes to usage
> of resources (RAM, disk space) mercurial is (sometimes _much_) more
> efficient, too. -- Sorry for sounding a bit like a commercial, but I
> was quite skeptical my self until Thomas (I CCed him) convinced me to
> actually try it, and now I'm really a fan...  ;-)

No, I know that mercurial definitely has some very strong points, though
I've seen a lot of arguing over their relative merits.  I'm slightly
nervous about the name-based repository layout though, as it's such a
horrible lose in the case of CVS -- git's "content based" storage is
very appealing in that sense.

I'm also slightly confused by the relationship between git and mercurial
-- can mercurial clone/pull/push from/to a git tree and vice-versa?

Thanks,

-Miles

-- 
Run away!  Run away!

Re: Switching to Subversion

[Thomas Arendsen Hein]

* Miles Bader <miles.bader@necel.com> [20061113 09:57]:
> Sascha Wilde <wilde@sha-bang.de> writes:
> > Sorry for sounding a bit like a commercial, but I
> > was quite skeptical my self until Thomas (I CCed him) convinced me to
> > actually try it, and now I'm really a fan...  ;-)

I'm the Thomas which Sascha mentioned and I'm now subscribed to the
list, at for the course of this discussion.

> No, I know that mercurial definitely has some very strong points, though
> I've seen a lot of arguing over their relative merits.  I'm slightly
> nervous about the name-based repository layout though, as it's such a
> horrible lose in the case of CVS

That's actually one of the strong points of Mercurial. Because of
the name based layout the directory traversal order is more
efficient for filesystems with linear directory storage (like ext[2-4])

> I'm also slightly confused by the relationship between git and mercurial
> -- can mercurial clone/pull/push from/to a git tree and vice-versa?

There is a fast and incremental converter from git to Mercurial
included with Mercurial for over a year now and the next release of
Mercurial (expected in a few days) can export patches not only in
the standard patch format, but in git's extended patch format which
preserves copies/renames/executable-bit/binaries, too.

Thomas

-- 
Email: thomas@intevation.de
http://intevation.de/~thomas/

Re: Switching to Subversion

[Juanma Barranquero]

> There is a fast and incremental converter from git to Mercurial
> included with Mercurial for over a year now and the next release of
> Mercurial (expected in a few days)

At least Mercurial runs on Windows.

No offense intended, Mercurial seems nice, but I think it would be too
bold switching Emacs development to a SCM scarcely one and a half year
old.

It's not that there aren't good SCMs out there, is that most of them
aren't mature. Not even git, I'd say.

                    /L/e/k/t/u

Re: Switching to Subversion

[Miles Bader]

Thomas Arendsen Hein <thomas@intevation.de> writes:
>> No, I know that mercurial definitely has some very strong points, though
>> I've seen a lot of arguing over their relative merits.  I'm slightly
>> nervous about the name-based repository layout though, as it's such a
>> horrible lose in the case of CVS
>
> That's actually one of the strong points of Mercurial. Because of
> the name based layout the directory traversal order is more
> efficient for filesystems with linear directory storage (like ext[2-4])

My question is whether it has negative effects though.  Name-based
layouts are indeed often very efficient, but might tie things to names
too much.

I tried to use mercurial a long time ago, and noticed it seemed to have
only very poor renaming support -- renames basically seemed to show up
as delete+add (mind you git's not all that great either in that sense).

-Miles

-- 
Everywhere is walking distance if you have the time.  -- Steven Wright

Re: Switching to Subversion

[Juanma Barranquero]

On 11/13/06, Miles Bader <miles.bader@necel.com> wrote:

> I tried to use mercurial a long time ago, and noticed it seemed to have
> only very poor renaming support -- renames basically seemed to show up
> as delete+add

That's also true in Subversion (well, copy+delete, I think) though
true renames are very much requested and so they will eventually be
implemented (I'm not tracking Subversion development closely, so I
don't know whether that will be sooner rather than later).

                    /L/e/k/t/u

Re: Switching to Subversion

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 11/13/06, Miles Bader <miles.bader@necel.com> wrote:
>
>> I tried to use mercurial a long time ago, and noticed it seemed to have
>> only very poor renaming support -- renames basically seemed to show up
>> as delete+add
>
> That's also true in Subversion (well, copy+delete, I think) though
> true renames are very much requested and so they will eventually be
> implemented (I'm not tracking Subversion development closely, so I
> don't know whether that will be sooner rather than later).

You see me surprised.  I had thought that file tree movements (which
seem to be close enough to renaming) were one of the major selling
points of Subversion over CVS.  Not having tried it myself, I can't
judge this, but I would have expected something different from the
announcements and goals I seem to remember.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Switching to Subversion

[Juanma Barranquero]

On 11/13/06, David Kastrup <dak@gnu.org> wrote:

> You see me surprised.  I had thought that file tree movements (which
> seem to be close enough to renaming) were one of the major selling
> points of Subversion over CVS.

In the Project Roadmap
(http://subversion.tigris.org/project_status.html) you can follow a
link to "open issues marked for 1.5 or 1.5-consider". Item 898 is
"implement true renames".

                    /L/e/k/t/u

Re: Switching to Subversion

[Bill Wohler]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 11/13/06, Miles Bader <miles.bader@necel.com> wrote:
>
>> I tried to use mercurial a long time ago, and noticed it seemed to have
>> only very poor renaming support -- renames basically seemed to show up
>> as delete+add
>
> That's also true in Subversion (well, copy+delete, I think) though
> true renames are very much requested and so they will eventually be
> implemented (I'm not tracking Subversion development closely, so I
> don't know whether that will be sooner rather than later).

Just to be clear: the revision history is maintained. If you rename
foo to bar to baz and do "svn log baz", you see all of the changes to
foo.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

Re: Switching to Subversion

[Sascha Wilde]

Miles Bader <miles.bader@necel.com> wrote:

> I tried to use mercurial a long time ago, and noticed it seemed to have
> only very poor renaming support -- renames basically seemed to show up
> as delete+add (mind you git's not all that great either in that sense).

This was much improved recently.  You can rename/move files around in a
mercurial repository and the files history will be preserved.

Thomas, is this part of the latest release, or still only in the
development version?

cheers
sascha
-- 
Sascha Wilde
Wer HTML postet oder gepostetes HTML quotet oder sich gepostetes oder
gequotetes HTML beschafft, um es in Verkehr zu bringen, wird geplonkt.

Re: Switching to Subversion

[Miles Bader]

Sascha Wilde <wilde@sha-bang.de> writes:
>> I tried to use mercurial a long time ago, and noticed it seemed to have
>> only very poor renaming support -- renames basically seemed to show up
>> as delete+add (mind you git's not all that great either in that sense).
>
> This was much improved recently.  You can rename/move files around in a
> mercurial repository and the files history will be preserved.

That's good to hear.

One point which concerns me with is how renaming interacts with merging
-- that's one reason why representing a rename as del+add is problematic.

For instance, if I rename A->B, and then later merge a branch where the
author made a change to A ... what happens?  What if I rename A->B, and
then merge a branch where the author renamed A->C and made
changes to C?

Thanks,

-Miles

-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: Switching to Subversion

[Juanma Barranquero]

On 11/13/06, Miles Bader <miles@gnu.org> wrote:

> One point which concerns me with is how renaming interacts with merging

You can read Subversion's take on merge tracking at
http://subversion.tigris.org/merge-tracking/

                    /L/e/k/t/u

Re: Switching to Subversion

[Stefan Monnier]

> For instance, if I rename A->B, and then later merge a branch where the
> author made a change to A ... what happens?  What if I rename A->B, and
> then merge a branch where the author renamed A->C and made
> changes to C?

Or rename directory A to B and merge a branch which added a file A/toto.c,


        Stefan

Re: Switching to Subversion

[Thomas Arendsen Hein]

* Miles Bader <miles@gnu.org> [20061113 10:41]:
> Sascha Wilde <wilde@sha-bang.de> writes:
> > I have to plug mercurial[0] in this thread.  It's a distributed SCM
> > written in python, which has a ui which is very similar to cvs, too
> > (at least for all operation where this is possible).  
> 
> Here's Keith Packard's (of X11 fame) rather well-argued take on the
> issue:
> 
>    http://keithp.com/blog/Repository_Formats_Matter.html
> 
> He provides pretty good arguments _against_ subversion, but also
> addresses mercurial vs. git a bit (mercurial is in some sense a riff on
> git, btw).

If I interpret "riff" as "rip off", I have to disagree here.

Citing a presentation of the original author of Mercurial:
(the Ottawa Linux Symposium slides on
 http://www.selenic.com/mercurial/wiki/index.cgi/Presentations)
|   Early History Of Mercurial
|
| April 6, 2005:
|   Bitmover announces end of gratis version of Bitkeeper
|   Linus mentions he's looking at alternatives
|   I start working on Mercurial
|   Linus starts working on Git
| April 8:
|   Linus releases initial nearly useless Git snapshot
| April 19:
|   Mercurial 0.1 released
|   features: familiar interface, efficient storage,
|   commit/checkout/clone/pull/merge
| April 20:
|   Linus fails to destroy Git in a timely fashion


> Here's the final few paragraphs:
>
>    I know Git suffers from its association with the wild and wooly kernel
>    developers, but they've pushed this tool to the limits and it continues
>    to shine. Right now, there's nothing even close in performance,
>    reliability and functionality.

Mercurial comes close in some aspects and is faster in others. In
fact git is much slower and consumes huge amounts of disk space if
you don't regularly do git-pack-objects. Which Mercurial such
cleanup work isn't needed.

And the blog says that the repository format of git is much more
stable, because it saves one file for each object while Mercurial
appends to file logs and truncates to the last file log size when a
commit or pull gets interrupted. But he doesn't mention that when
you start packing objects you'll move around all your history and in
case of trouble you'll have trouble with exactly this history.
I'm not saying that git will kill your data, but I'm saying that I
consider this at least as dangerous to your data as a simple
truncate (which only is done while a write lock is held).

Thomas

-- 
Email: thomas@intevation.de
http://intevation.de/~thomas/

Re: Switching to Subversion

[Miles Bader]

Thomas Arendsen Hein <thomas@intevation.de> writes:
>> He provides pretty good arguments _against_ subversion, but also
>> addresses mercurial vs. git a bit (mercurial is in some sense a riff on
>> git, btw).
>
> If I interpret "riff" as "rip off", I have to disagree here.

Riff does not mean "rip off."

-Miles
-- 
Any man who is a triangle, has thee right, when in Cartesian Space, to
have angles, which when summed, come to know more, nor no less, than
nine score degrees, should he so wish.  [TEMPLE OV THEE LEMUR]

Re: Switching to Subversion

[Sascha Wilde]

Miles Bader <miles.bader@necel.com> wrote:

> Thomas Arendsen Hein <thomas@intevation.de> writes:
>>> He provides pretty good arguments _against_ subversion, but also
>>> addresses mercurial vs. git a bit (mercurial is in some sense a riff on
>>> git, btw).
>>
>> If I interpret "riff" as "rip off", I have to disagree here.
>
> Riff does not mean "rip off."

So what does it mean here?  I'm no native speaker and wasn't able to
find something in the dictionary which seemed to fit in the context.

sascha
-- 
Sascha Wilde : "GUIs normally make it simple to accomplish simple 
             : actions and impossible to accomplish complex actions."
             : (Doug Gwyn - 22/Jun/91 in comp.unix.wizards)

Re: Switching to Subversion

[Thomas Arendsen Hein]

* Miles Bader <miles.bader@necel.com> [20061113 14:18]:
> Thomas Arendsen Hein <thomas@intevation.de> writes:
> >> He provides pretty good arguments _against_ subversion, but also
> >> addresses mercurial vs. git a bit (mercurial is in some sense a riff on
> >> git, btw).
> >
> > If I interpret "riff" as "rip off", I have to disagree here.
> 
> Riff does not mean "rip off."

My dictionary only provided translations which I don't fit to the
context for me. What do you mean?

Thomas

-- 
Email: thomas@intevation.de
http://intevation.de/~thomas/

Re: Switching to Subversion

[Miles Bader]

Thomas Arendsen Hein <thomas@intevation.de> writes:
>> Riff does not mean "rip off."
>
> My dictionary only provided translations which I don't fit to the
> context for me. What do you mean?

I'd say it means something like "a creative response to".  Clearly
mercurial _was_ a response to git, and sort of occupies the same "idea
space" to a degree, but it also attempts to provide its own unique
elements.

-miles

-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

Re: Switching to Subversion

[Richard Stallman]

We will not change the version control system for Emacs in the near term,
so this discussion of the merits of various version control systems is
a distraction.  Would those who want to discuss it please move
the discussion off this list?

Re: Switching to Subversion

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> so this discussion of the merits of various version control systems is
> a distraction.  Would those who want to discuss it please move
> the discussion off this list?

Does anybody know if there's a general "gnu-source-control" list for
this kind of discussion?  If not, should there be?

This is an issue that many free software projects have been wrestling
with lately, and I think it would be good to have a place to discuss it.

-Miles
-- 
((lambda (x) (list x x)) (lambda (x) (list x x)))

Re: Switching to Subversion

[joakim]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 11/12/06, Richard Stallman <rms@gnu.org> wrote:
>
>> Before considering use of subversion for Emacs I would have to use it
>> for something else, to see what it is like.
>
> Sounds reasonable. I think you'll find Subversion is designed to look
> just like a better CVS. The command set is very similar.
>
> There are quite a lot other good SCM programs out there (Arch,
> Monotone, svk), but they are far less mature and, in my (limited)
> tests, the user experience is very different. Arch filenames give me
> headaches.

I've used a number of these superficially, mostly as a user that wants
to checkout and build stuff regularily, and maintain some local
patches. So, for what its worth, heres my experiences:

CVS: updating from a central repos is easy, but maintaining local
patches quickly gets out of hand

Arch: updating from a central repos is often slow and error prone even
for small projects. Using the alternative implementation Baz helps.

SVN: most things are easy and intuitive to do, like updating,
branching, etc. The backend DB does get into weird states at times,
but it was reoverable. Also, this seems to be gone with recent SVN.
(this was together with Trac which is a really good bugtracker/wiki
thing that integrates with SVN)

git: One savannah project I work with has a central CVS repos. In
order to maintain a number of local patches I imported this into a git
repos. Then I worked on top of this with a tool called stg that handles
different patches. Importing the CVS repos takes hours, even for this
project which isnt anything like emacs in size. Then, any git
operation is for me totaly unintuitive, except for the things I do
through the stg frontend, which is very easy(make new patches, pop/push
them, sync with cvs).


> (Yes, I'm an una(bash|sham)ed Subversion proponent :)
>
>                    /L/e/k/t/u

-- 
Joakim Verona

Re: Switching to Subversion

[Juanma Barranquero]

On 11/13/06, joakim@verona.se <joakim@verona.se> wrote:

> SVN: most things are easy and intuitive to do, like updating,
> branching, etc. The backend DB does get into weird states at times,
> but it was reoverable. Also, this seems to be gone with recent SVN.
> (this was together with Trac which is a really good bugtracker/wiki
> thing that integrates with SVN)

Yeah, I used Trac professionaly for about a year and it's great. Can
only dream of how nice Emacs development would be with it :) (but it's
a no-no because Trac is not designed to allow most ops from e-mail,
IIRC).

                    /L/e/k/t/u

Re: Switching to Subversion

[joakim]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 11/13/06, joakim@verona.se <joakim@verona.se> wrote:
>
>> SVN: most things are easy and intuitive to do, like updating,
>> branching, etc. The backend DB does get into weird states at times,
>> but it was reoverable. Also, this seems to be gone with recent SVN.
>> (this was together with Trac which is a really good bugtracker/wiki
>> thing that integrates with SVN)
>
> Yeah, I used Trac professionaly for about a year and it's great. Can
> only dream of how nice Emacs development would be with it :) (but it's
> a no-no because Trac is not designed to allow most ops from e-mail,
> IIRC).

The Trac community is very friendly, and I asked this question on
#Trac.  They directed me to
http://trac-hacks.org/wiki/EmailtoTracScript

There are a number of other useful plugins there, like xml-rpc
interfaces etc.


>
>                    /L/e/k/t/u
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Joakim Verona
http://www.verona.se

Re: Switching to Subversion

[Bill Wohler]

I knew that Java had switched to the GPL, but James' note is of
relevance:

    Subject: James Gosling: On The Open Sourcing of Java. Bonus: Duke
    is Open Sourced!
    Newsgroups: java.net JavaDesktop Features
    Date: Mon, 13 Nov 2006 00:00:00

    I'm really happy that after months of arguing and analysis, we
    finally agreed on using the GPL version 2 with the classpath
    exception as the license for JavaSE. We're also taking the first
    couple of baby steps in getting actual source code relicensed. All
    of it will follow, eventually. But there's a lot of work to do,
    like migrating millions of lines of code from TeamWare to
    Mercurial. For extra bonus fun, we're open sourcing Duke.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

Re: Switching to Subversion

[Richard Stallman]

    Sounds reasonable. I think you'll find Subversion is designed to look
    just like a better CVS. The command set is very similar.

It surely must look different in some ways, or people would not prefer
it.  I think it only means that the differences do not seem bad to you.
What I will think of them, I don't know.

Re: Switching to Subversion

[Juliusz Chroboczek]

> Before considering use of subversion for Emacs

Richard, please don't do that.  Centralised revision control systems
are not suitable for Free Software.

Use Git, use Mercurial, use Darcs, use Monotone, use Arch, I don't
care.  But please use a distributed revision control system.

When you use a centralised RCS, either you have commit rights, in
which case all is fine, or you don't, in which case the RCS
degenerates to just a way to get the latest version of the software.

With a distributed RCS, I don't need commit rights in your repository
to use the RCS if I want to do some hacking on Emacs, I just branch
from your repository and create a local branch on my machine.

Thanks for listening,

                                        Juliusz Chroboczek

Re: Switching to Subversion

[Masatake YAMATO]

> > Before considering use of subversion for Emacs
> 
> Richard, please don't do that.  Centralised revision control systems
> are not suitable for Free Software.
> 
> Use Git, use Mercurial, use Darcs, use Monotone, use Arch, I don't
> care.  But please use a distributed revision control system.

Svk, a decentralized revision control system stacked on subversion is not enough?

 http://svk.bestpractical.com/view/HomePage

I don't know the detail, however, psvn.el deals with svk, too.

Masatake

Re: Switching to Subversion

[Eric Hanchrow]

>>>>> "Juliusz" == Juliusz Chroboczek <jch@pps.jussieu.fr> writes:

    >> Before considering use of subversion for Emacs Juliusz>
    Juliusz> Richard, please don't do that.  Centralised revision
    Juliusz> control systems are not suitable for Free Software.

For what it's worth, here's an essay that argues the exact opposite:
http://web.mit.edu/~ghudson/thoughts/bitkeeper.whynot

The title is "Why Bitkeeper Isn't Right For Free Software", but it's
also about why _decentralized_ development isn't right for Free
Software.

-- 
I've laid out in my will that my heirs should continue working
on my .emacs
        -- johnw

Re: Switching to Subversion

[Miles Bader]

Eric Hanchrow <offby1@blarg.net> writes:
> For what it's worth, here's an essay that argues the exact opposite:
> http://web.mit.edu/~ghudson/thoughts/bitkeeper.whynot
>
> The title is "Why Bitkeeper Isn't Right For Free Software", but it's
> also about why _decentralized_ development isn't right for Free
> Software.

A brief glance suggests that he's not arguing against decentralized
development at all, but rather against what he calls "the pyramid model"
with a single gatekeeper at the top.  They're not the same thing.
Decentralized source-control systems tend to be very flexible and can
support many development models, with varying degrees of centralization
and control.

-Miles

-- 
自らを空にして、心を開く時、道は開かれる

Re: CVS commits and logs

[Richard Stallman]

    >     Yes.  A single merge-commit to the unicode-2 branch represents many,
    >     many changes on the trunk (hundreds of files, often multiple changes to
    >     each file), so I don't include changelog info in the CVS log entry at
    >     all.  The CVS log entry more or less says "merge from trunk of
    >     changesets X-Y."

    Well, that sort of indirection is the idea, and it's currently
    possible to find the source log entries, but not using CVS alone:  the
    changeset information in the merge log refers to _arch_ changesets

Why does merging one CVS branch into another have anything to do with
arch?

What does arch have to do with this anyway?

    Even with these tags, it would still be somewhat annoying for someone
    to track down the exact original commit logs, but I don't think
    there's really any practical alternative.

One practical alternative is that we stop using arch.

Maybe there are others -- such as changing your merge process
so that it extracts proper CVS log info out of the arch data.

Re: CVS commits and logs

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     Well, that sort of indirection is the idea, and it's currently
>     possible to find the source log entries, but not using CVS alone:  the
>     changeset information in the merge log refers to _arch_ changesets
>
> Why does merging one CVS branch into another have anything to do with
> arch?
>
> What does arch have to do with this anyway?

Arch is the tool I use -- it makes the process _much_ easier.  I
wouldn't do it if had to use CVS only (CVS is not particular good at
this sort of thing).

>     Even with these tags, it would still be somewhat annoying for someone
>     to track down the exact original commit logs, but I don't think
>     there's really any practical alternative.
>
> One practical alternative is that we stop using arch.

Not only would using CVS only be a lot more work (it's not something I
want to do), but it _would not fix the problem_.

If arch were dropped, assuming you could find somebody to do merges
using CVS (I wouldn't), they'd be in exactly the same position we are
today:  they'd need to either find an acceptable way of recording
"indirection" (probably via tags as I mentioned before), or write tools
to grovel through the commit logs constructing new logs for merging, and
do file-by-file merges.

> Maybe there are others -- such as changing your merge process
> so that it extracts proper CVS log info out of the arch data.

If somebody has a concrete suggestion, by all means give it.  I've made
one (adding CVS tags to allow doing the the necessary "indirection"
without worrying about arch), which I think is imperfect, but certainly
a workable solution.

I think it's also worth thinking about this though:  has there ever been
even a _single_ instance of a developer being inconvenienced by the
current state of things?  How much pain is it worth to "fix" something
which hasn't actually had any noticeably bad effect?

-Miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: CVS commits and logs

[Richard Stallman]

    Not only would using CVS only be a lot more work (it's not something I
    want to do), but it _would not fix the problem_.

Please explain why not.  Your previous message said the problem
results from use of arch.  Are you now saying that a similar problem
happens when CVS is used to merge one branch into another?

If so, please describe the scenario and the problem.

Remember that we are talking about merging the unicode-2 branch
into the trunk.

    If somebody has a concrete suggestion, by all means give it.  I've made
    one (adding CVS tags to allow doing the the necessary "indirection"
    without worrying about arch), which I think is imperfect, but certainly
    a workable solution.

I do not understand what that means.  I am not an expert on CVS.
Please explain to me the solution you proposed, and what problem
it is supposed to solve.

Re: CVS commits and logs

[Reiner Steib]

On Mon, Nov 06 2006, Richard Stallman wrote:

> I dislike multi-file CVS commits specifically because of the clutter
> of having the entire change log entry in the log of each file.

I think for changes like the examples below[1], multi-file commits
make sense, because the changes are closely related.

I could most probably find more such examples in Gnus.  When I
investigated which bug-fixes from the Gnus trunk need to be merged
into the stable branch and when I merged the Gnus changes done on
Emacs' repository back to Gnus' repository, multi-file commit messages
helped me to identify related changes in other files.

Bye, Reiner.

[1]
,----
| 2006-09-07  Reiner Steib  <Reiner.Steib@gmx.de>
| 
| 	* international/latexenc.el (latex-inputenc-coding-alist): Add cp858.
| 
| 	* international/code-pages.el: Add cp858.
`----

,----
| 2006-05-30  Reiner Steib  <Reiner.Steib@gmx.de>
| 
| 	* textmodes/flyspell.el (turn-on-flyspell, turn-off-flyspell):
| 	New functions.
| 
| 	* textmodes/text-mode.el (text-mode-hook): Use turn-on-flyspell.
`----

,----
| 2006-04-06  Reiner Steib  <Reiner.Steib@gmx.de>
| 
| 	* files.el: Move some `safe-local-variable' declarations to the
| 	respective files.
| 
| 	* textmodes/ispell.el (ispell-check-comments)
| 	(ispell-local-dictionary): Mark as safe.
| 
| 	* abbrev.el (abbrev-mode): Mark as safe.
|[...]
`----
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: CVS commits and logs

[Eli Zaretskii]

> From: Reiner Steib <reinersteib+gmane@imap.cc>
> Date: Tue, 07 Nov 2006 19:07:18 +0100
> Cc: emacs-devel@gnu.org, wohler@newt.com, Miles Bader <miles@gnu.org>
> 
> When I investigated which bug-fixes from the Gnus trunk need to be
> merged into the stable branch and when I merged the Gnus changes
> done on Emacs' repository back to Gnus' repository, multi-file
> commit messages helped me to identify related changes in other
> files.

Why couldn't you find those changes through lisp/gnus/ChangeLog?  They
should all appear near one another.

Re: CVS commits and logs

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> Why couldn't you find those changes through lisp/gnus/ChangeLog?  They
> should all appear near one another.

Probably he could have, but the closer the commit log and the changelog
entry are in form, the easier it is.

[A similar issue is when people "fix up" changelog entries when merging
from one branch to another; sometimes this is unavoidable, but often
it's gratuitous.  When I want to find the changelog entry for the same
change in two different branches (gnus/emacs usually), this sort of
change can be a real headache.]

-Miles

-- 
My books focus on timeless truths.  -- Donald Knuth

Re: CVS commits and logs

[Reiner Steib]

On Wed, Nov 08 2006, Miles Bader wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>> Why couldn't you find those changes through lisp/gnus/ChangeLog?  They
>> should all appear near one another.

I don't remember the details exactly.  IIRC, I often had to look at
the output of `C-x v l' (vc-print-log), the current diff (`d' =
`log-view-diff') and the diff between the two versions of the file
(Emacs vs. Gnus repository).  Searching in the Changelog file for
possible related changes would make it more complicated.

It's also possible that related changes are not mentioned in the same
ChangeLog file, say lisp/ChangeLog and lisp/gnus/ChangeLog
(e.g. changes in pgg*.el or mail/*.el which also require changes in
gnus/mml*.el).  [I'm not sure that there were such cases, though.]

> Probably he could have, but the closer the commit log and the changelog
> entry are in form, the easier it is.

ACK.

In general, I agree to the guidelines and it's a good idea to describe
the rules in some file in admin/.  WRT the multi-file commits, it
would be nice if there's a PCL-CVS's commit command that automates
splitting a commit like this one, if we don't want multi-file commits.

,----
| 2006-04-06  Reiner Steib  <Reiner.Steib@gmx.de>
| 
| 	* files.el: Move some `safe-local-variable' declarations to the
| 	respective files.
| 
| 	* textmodes/ispell.el (ispell-check-comments)
| 	(ispell-local-dictionary): Mark as safe.
| 
| 	* abbrev.el (abbrev-mode): Mark as safe.
|[...]
`----

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: CVS commits and logs

[Eli Zaretskii]

> From: Bill Wohler <wohler@newt.com>
> Date: Sun, 05 Nov 2006 15:15:06 -0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >   . CVS log entries should be simply the ChangeLog entries with the
> >     file name and the leading TABs stripped.
> 
> I agree if only one file is committed. However, if multiple files are
> committed, I'd say leave the file names and strip the leading TABs.

But the next rule says each commit should be only one file, so there's
no ``if''.

> >   . Each file should be committed separately, even if the changes are
> >     related, and the CVS log entry should be for the changes in that
> >     file only.  In particular, the modified files and the ChangeLog
> >     file with the appropriate log entry should be committed separately
> >     (thus the CVS log entries for ChangeLog files should never include
> >     log entries for the modified files).  Exception: it is okay to
> >     commit several changes to a single ChangeLog file in one "cvs ci"
> >     command if those changes are related to the same feature/bugfix.
> 
> This isn't clear. In the first sentence you say, "even if the changes
> are related" but the exception says--paraphrased--"except if the
> change are related". Which is it?

The exception is from the second sentence that talks about ChangeLog
files only.

> by enumerating all of the file names in a single log message, you
> can see easily which files are affected by a given change.

As I understand, this can be seen from the ChangeLog itself, you don't
need to go to CVS.

Also, if multiple file commits are allowed, nothing prevents people
from committing unrelated changes in one go.

> I check in the ChangeLog at the same time as I check in the file whose
> change it describes. It's easy and the ChangeLog check-in is less
> prone to be forgotten. It seems this is a common practice. Is there a
> good reason for your rule?

Those are not my rules, I just took a liberty of describing the rules
Richard requested me to follow a long time ago.

Switching to Subversion

[Jim Blandy]

I designed the Subversion repository structure, and began the work on
the first filesystem implementation, so I can answer some of the "what
were they thinking?" questions that have come up on this thread.

We were aware from the beginning of the importance of merging.  We had
long discussions on what merging should mean, and the fellow who
handles version control for HP's inkjet printer division (they use a
big changeset engine) came to talk to us about changesets.  We all
agreed that changeset-based systems with interfaces like Darcs and
BitKeeper were The Right Thing, and the most useful way to think about
the whole activity of collaborative development.

However, we didn't implement that because we couldn't see any way to
do it in a way that scales to very old repositories.  For example, the
GCC repository has 118807 revisions in it at the moment, and handles
them just fine.  I don't see how a system with a repository structure
like Darcs (which I use and absolutely love) is going to handle that,
unless you're willing to rearrange your repository to trade speed for
historic detail.  And there have been comments from Larry McVoy to the
effect of, "big deal, everyone falls down with a few tens of thousands
of revisions".  Subversion has demonstrated that that's not so.

>From discussions with other people who follow these things more
closely, I understand that Mercurial has an excellent repository
structure: very compact, very fast, and very versatile.  The
Subversion project has plans --- which should be weighed as just that,
plans and talk --- to incorporate some of Mercurial's characteristics
in its merge support.

I do occasionally see a tendency in programming circles for people who
have recognized others' good ideas to adopt the strut earned by the
person who actually had them.  It always looks a little strange.