Re: VMS support

[Stefan Monnier]

> If you only can spend a few minutes at a time when doing this (and
> I do), you can't write ChangeLogs when doing the work because they
> will conflict on updates.

You should place the ChangeLog text somewhere where it won't conflict
(e.g. some temp file, or further down in the ChangeLog file where there
will hopefully not be any changes) and then move it into place when you
do the commit.  Or you simply use C-x ^ r to auto-resolve the conflicts.

> When updating you get unnecessary conflicts that need to be resolved.

Again, since you're removing unused code, conflicting changes should be
relatively infrequent.  Doesn't sound like a big deal.

> When working offline you can't cvs remove files.

Yes, it's an irksome part of CVS.  I even submitted a patch to fix it
(together with a patch to add files offline as well) and used it for
a while.  But nowadays, I just directly edit the CVS/Entries file when
faced with this problem (after all, all it takes is to add a "-" at the
right place).

> If you cvs remove files before tagging, the tag won't apply to that
> file.

Really?  Duh, that's a nasty bug.  I guess it means you should indeed
refrain from "cvs removing" before the commit.  Instead, you should only
"rm" the files, and keep track of them, so that when you commit you do
"cvs tag; cvs rm <markedfiles>; cvs commit".  Kind of ugly indeed.

> On the other hand the gain is inexistent.

If someone ever intends to pick up this code and do something useful
with it, having it cleanly delimited by before/after tags is
very helpful.  If it's not commited as a single commit, you risk having
your change be interleaved with other unrelated changes.  Of course, if
nobody ever picks it up, the gain is indeed inexistent, but the cost
really seems pretty minor compared to the effort needed to figure out
how to remove the code (which parts to remove, etc...).

Thank you for the effort,


        Stefan