all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* VMS support
       [not found] ` <87d4l76ntu.fsf@ambire.localdomain>
@ 2008-07-21 19:52   ` Chong Yidong
  2008-07-23 10:27     ` Thien-Thi Nguyen
  0 siblings, 1 reply; 19+ messages in thread
From: Chong Yidong @ 2008-07-21 19:52 UTC (permalink / raw)
  To: Thien-Thi Nguyen; +Cc: emacs-devel

What is the situation with the VMS support?  AFAICT, ttn was working on
getting it to work again, but I haven't heard anything about this
project since.  Dan Nicolaescu has suggested removing VMS support for
the purpose of code cleanup.  WDYT?




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: VMS support
  2008-07-21 19:52   ` VMS support Chong Yidong
@ 2008-07-23 10:27     ` Thien-Thi Nguyen
  2008-07-23 20:05       ` Stefan Monnier
  2008-07-24  2:23       ` Richard M Stallman
  0 siblings, 2 replies; 19+ messages in thread
From: Thien-Thi Nguyen @ 2008-07-23 10:27 UTC (permalink / raw)
  To: emacs-devel

() Chong Yidong <cyd@stupidchicken.com>
() Mon, 21 Jul 2008 15:52:38 -0400

   What is the situation with the VMS support?  AFAICT, ttn was working
   on getting it to work again, but I haven't heard anything about this
   project since.

Emacs 21.2 was the last known-good port, but that requires out-of-tree
code due to legal issues (specifically: the author of a big chunk of
VMS-specific code filed in 1992 a "copyright disclaimer" only, which is
not equal in force to a "copyright assignment" IIUC, and repeated
attempts to get the (standard) past/future copyright assignment from him
(by me and perhaps others) have failed, even though he has indicated in
200[45]-ish email that he is willing to do so).  These legal issues
might still be resolvable (i can try engaging him again), but i cannot
say for sure.

More details, including (lack-of-)progress/technical info, are at:
http://www.gnuvola.org/software/emacs-for-vms/

   Dan Nicolaescu has suggested removing VMS support for the purpose of
   code cleanup.  WDYT?

I think removing VMS support is fine, but not for the purpose of code
cleanup.  That reason implies that clean VMS support should be kept.
A better reason is that VMS is proprietary and Emacs users on VMS have
not shown sufficient interest in it.

If VMS support is to be removed, please do a complete job and remove it
from the Lisp and config/build/doc/admin parts of Emacs, as well.

thi




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: VMS support
  2008-07-23 10:27     ` Thien-Thi Nguyen
@ 2008-07-23 20:05       ` Stefan Monnier
  2008-07-24  7:44         ` Thien-Thi Nguyen
  2008-07-24  2:23       ` Richard M Stallman
  1 sibling, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2008-07-23 20:05 UTC (permalink / raw)
  To: Thien-Thi Nguyen; +Cc: emacs-devel

>    What is the situation with the VMS support?  AFAICT, ttn was working
>    on getting it to work again, but I haven't heard anything about this
>    project since.

> Emacs 21.2 was the last known-good port, but that requires out-of-tree
> code due to legal issues (specifically: the author of a big chunk of
> VMS-specific code filed in 1992 a "copyright disclaimer" only, which is
> not equal in force to a "copyright assignment" IIUC, and repeated
> attempts to get the (standard) past/future copyright assignment from him
> (by me and perhaps others) have failed, even though he has indicated in
> 200[45]-ish email that he is willing to do so).  These legal issues
> might still be resolvable (i can try engaging him again), but i cannot
> say for sure.

The only question that I think is really relevant is: is there some hope
that someone will pursue this work (both the copyright assignment issue
and the update of the code to the Emacs-CVS-trunk codebase) in some
foreseeable future.


        Stefan




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: VMS support
  2008-07-23 10:27     ` Thien-Thi Nguyen
  2008-07-23 20:05       ` Stefan Monnier
@ 2008-07-24  2:23       ` Richard M Stallman
  1 sibling, 0 replies; 19+ messages in thread
From: Richard M Stallman @ 2008-07-24  2:23 UTC (permalink / raw)
  To: Thien-Thi Nguyen; +Cc: emacs-devel

    Emacs 21.2 was the last known-good port, but that requires out-of-tree
    code due to legal issues (specifically: the author of a big chunk of
    VMS-specific code filed in 1992 a "copyright disclaimer" only, 

We can use code with a copyright disclaimer.
So if that was indeed the reason for removing the code,
someone misunderstood the issue.

Perhaps there was some other reason.




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: VMS support
  2008-07-23 20:05       ` Stefan Monnier
@ 2008-07-24  7:44         ` Thien-Thi Nguyen
  2008-07-24 13:59           ` Stefan Monnier
  0 siblings, 1 reply; 19+ messages in thread
From: Thien-Thi Nguyen @ 2008-07-24  7:44 UTC (permalink / raw)
  To: emacs-devel

() Stefan Monnier <monnier@iro.umontreal.ca>
() Wed, 23 Jul 2008 16:05:01 -0400

   The only question that I think is really relevant is: is there
   some hope that someone will pursue this work (both the
   copyright assignment issue and the update of the code to the
   Emacs-CVS-trunk codebase) in some foreseeable future.

Personally speaking, there is hope, in two parts:

a/ I received a clarification about the nuances between
   "disclaiming interest" and "copyright assignment" from the FSF
   copyright clerk (thanks!), which can be summed up (IIUC) as:
   Richard Levitte's code is ok to use, if i copyright the
   (extensive) changes i've made to it, since i myself have done
   the past/future assignment.

b/ I have a soft spot for VMS, though that spot shrinks w/ time.
   If i can finangle a $ituation to provide a port of Emacs 22 (or
   Emacs 23, once it settles), i will do it, otherwise no.

Having said that, i haven't queried potential funders yet, and the
negotiation process may take a while, and it may ultimately block
indefinitely, so "in some foreseeable future" is not indicated.

I say go ahead and zonk the VMS support.  If someone funds another
port (by me or whoever), previous source can always be re-dredged
and previous "expertise" can always be re-fudged. :-D

If anyone reading this is in a position to expedite b/ (above),
please feel free to contact me privately.

thi




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: VMS support
  2008-07-24  7:44         ` Thien-Thi Nguyen
@ 2008-07-24 13:59           ` Stefan Monnier
  2008-07-24 16:55             ` Dan Nicolaescu
  2008-07-24 17:34             ` Thien-Thi Nguyen
  0 siblings, 2 replies; 19+ messages in thread
From: Stefan Monnier @ 2008-07-24 13:59 UTC (permalink / raw)
  To: Thien-Thi Nguyen; +Cc: emacs-devel

> a/ I received a clarification about the nuances between
>    "disclaiming interest" and "copyright assignment" from the FSF
>    copyright clerk (thanks!), which can be summed up (IIUC) as:
>    Richard Levitte's code is ok to use, if i copyright the
>    (extensive) changes i've made to it, since i myself have done
>    the past/future assignment.

Good.

> b/ I have a soft spot for VMS, though that spot shrinks w/ time.
>    If i can finangle a $ituation to provide a port of Emacs 22 (or
>    Emacs 23, once it settles), i will do it, otherwise no.

The only meaningful merge in my mind is a merge with CVS trunk, not with
some previous released version of the code, otherwise you'll always have
to play catch up.

> I say go ahead and zonk the VMS support.  If someone funds another
> port (by me or whoever), previous source can always be re-dredged
> and previous "expertise" can always be re-fudged. :-D

OK, so we should get rid of the VMS code in one clean commit with a CVS
tag before and another after.  I think it's important for this commit to
be as clean as possible (i.e. it really removes all the VMS related
code and text), so that there won't be some future changes that remove
a bit more of the VMS support: this way the CVS tags will faithfully
include all the relevant code (and text).

I guess we should do the same for the Carbon port since it also seems
that nobody is interested in updating&maintaining it.


        Stefan




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: VMS support
  2008-07-24 13:59           ` Stefan Monnier
@ 2008-07-24 16:55             ` Dan Nicolaescu
  2008-07-24 19:58               ` Stefan Monnier
  2008-07-24 17:34             ` Thien-Thi Nguyen
  1 sibling, 1 reply; 19+ messages in thread
From: Dan Nicolaescu @ 2008-07-24 16:55 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Thien-Thi Nguyen, emacs-devel

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

  > > I say go ahead and zonk the VMS support.  If someone funds another
  > > port (by me or whoever), previous source can always be re-dredged
  > > and previous "expertise" can always be re-fudged. :-D
  > 
  > OK, so we should get rid of the VMS code in one clean commit with a CVS
  > tag before and another after.  I think it's important for this commit to
  > be as clean as possible (i.e. it really removes all the VMS related
  > code and text), so that there won't be some future changes that remove
  > a bit more of the VMS support: this way the CVS tags will faithfully
  > include all the relevant code (and text).

IMO doing it this way is too high of a burden and hence not very
feasible.  It pretty much forces this to be a one person job instead of
allowing it to be distributed.  
There are 397 references just to the VMS string just in the C code +
docs.  And there are probably many things that are only valid for VMS,
but are not explicitly mentioning the VMS string.

  > I guess we should do the same for the Carbon port since it also seems
  > that nobody is interested in updating&maintaining it.

Is this a go ahead?




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: VMS support
  2008-07-24 13:59           ` Stefan Monnier
  2008-07-24 16:55             ` Dan Nicolaescu
@ 2008-07-24 17:34             ` Thien-Thi Nguyen
  2008-07-24 20:00               ` Stefan Monnier
  1 sibling, 1 reply; 19+ messages in thread
From: Thien-Thi Nguyen @ 2008-07-24 17:34 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

() Stefan Monnier <monnier@IRO.UMontreal.CA>
() Thu, 24 Jul 2008 09:59:52 -0400

   The only meaningful merge in my mind is a merge with CVS trunk,
   not with some previous released version of the code, otherwise
   you'll always have to play catch up.

To port is to always play catch up.  E-then-N vs N-then-E, you're
better off letting the taxi driver handle the urban tactics...

thi




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: VMS support
  2008-07-24 16:55             ` Dan Nicolaescu
@ 2008-07-24 19:58               ` Stefan Monnier
  2008-07-27 18:41                 ` Dan Nicolaescu
  0 siblings, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2008-07-24 19:58 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: Thien-Thi Nguyen, emacs-devel

>> OK, so we should get rid of the VMS code in one clean commit with a CVS
>> tag before and another after.  I think it's important for this commit to
>> be as clean as possible (i.e. it really removes all the VMS related
>> code and text), so that there won't be some future changes that remove
>> a bit more of the VMS support: this way the CVS tags will faithfully
>> include all the relevant code (and text).

> IMO doing it this way is too high of a burden and hence not very
> feasible.  It pretty much forces this to be a one person job instead
> of allowing it to be distributed.   There are 397 references just to
> the VMS string just in the C code + docs.  And there are probably many
> things that are only valid for VMS, but are not explicitly mentioning
> the VMS string.

Well, there's doing a perfect jog and then there's doing a thorough job.
A perfect job is probably impossible.  But handling the 397 references
to vms in the C code shouldn't be that hard, and dealing with the rest
of the references in the Lisp code and in the manual shouldn't be that
hard either.  Sure, you're going to miss some implicit references, but
that's OK.

If you don't want to do it, then don't do it.

>> I guess we should do the same for the Carbon port since it also seems
>> that nobody is interested in updating&maintaining it.
> Is this a go ahead?

Yes, but with the same requirement of a clean removal.


        Stefan




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: VMS support
  2008-07-24 17:34             ` Thien-Thi Nguyen
@ 2008-07-24 20:00               ` Stefan Monnier
  2008-07-24 20:40                 ` Thien-Thi Nguyen
  0 siblings, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2008-07-24 20:00 UTC (permalink / raw)
  To: Thien-Thi Nguyen; +Cc: emacs-devel

>    The only meaningful merge in my mind is a merge with CVS trunk,
>    not with some previous released version of the code, otherwise
>    you'll always have to play catch up.

> To port is to always play catch up.  E-then-N vs N-then-E, you're
> better off letting the taxi driver handle the urban tactics...

I can assure you that it's not the same if your code is in the trunk vs
if your code is on some other branch: when I edit the the C code and see
an "#ifdef VMS" I'll try to pay attention to that code, even if I can't
test that my change doesn't break it.  If it's not in the trunk, I won't
see the #ifdef and you'll have to deal with the breakage.


        Stefan




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: VMS support
  2008-07-24 20:00               ` Stefan Monnier
@ 2008-07-24 20:40                 ` Thien-Thi Nguyen
  0 siblings, 0 replies; 19+ messages in thread
From: Thien-Thi Nguyen @ 2008-07-24 20:40 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

() Stefan Monnier <monnier@IRO.UMontreal.CA>
() Thu, 24 Jul 2008 16:00:03 -0400

   I can assure you that it's not the same if your code is in
   the trunk vs if your code is on some other branch: when I
   edit the the C code and see an "#ifdef VMS" I'll try to pay
   attention to that code, even if I can't test that my change
   doesn't break it.  If it's not in the trunk, I won't see
   the #ifdef and you'll have to deal with the breakage.

Whoever does porting work has to deal w/ the breakage, anyway,
regardless of the intention/care of others.  I appreciate your
saying you would take care, but the care you take is not the
only factor.

But that's enough from me on this topic.

thi




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: VMS support
  2008-07-24 19:58               ` Stefan Monnier
@ 2008-07-27 18:41                 ` Dan Nicolaescu
  2008-07-27 18:48                   ` Stefan Monnier
  0 siblings, 1 reply; 19+ messages in thread
From: Dan Nicolaescu @ 2008-07-27 18:41 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Thien-Thi Nguyen, emacs-devel

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

  > >> I guess we should do the same for the Carbon port since it also seems
  > >> that nobody is interested in updating&maintaining it.
  > > Is this a go ahead?
  > 
  > Yes, but with the same requirement of a clean removal.

Carbon is gone now.  There's a before-remove-carbon and a remove-carbon tag.
doc/emacs/macos.texi is still present, it looked like it might have some
text that is useful.  Someone that knows the platform would need to
handle that.  There's a note about it in admin/FOR-RELEASE.

Doing this a one big commit is _extremely_ inconvenient.  A thorough
removal can be done in steps too, and tags can help sort out the changes
easily.  The unnecessary red tape just adds extra work for absolutely
zero gain.




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: VMS support
  2008-07-27 18:41                 ` Dan Nicolaescu
@ 2008-07-27 18:48                   ` Stefan Monnier
  2008-07-27 19:06                     ` Dan Nicolaescu
  0 siblings, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2008-07-27 18:48 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: Thien-Thi Nguyen, emacs-devel

> Doing this a one big commit is _extremely_ inconvenient.  A thorough
> removal can be done in steps too, and tags can help sort out the changes
> easily.  The unnecessary red tape just adds extra work for absolutely
> zero gain.

Can't imagine why it's so inconvenient.  Care to give some example of
the difficulties it adds?


        Stefan




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: VMS support
  2008-07-27 18:48                   ` Stefan Monnier
@ 2008-07-27 19:06                     ` Dan Nicolaescu
  2008-07-27 19:31                       ` Stefan Monnier
  0 siblings, 1 reply; 19+ messages in thread
From: Dan Nicolaescu @ 2008-07-27 19:06 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Thien-Thi Nguyen, emacs-devel

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

  > > Doing this a one big commit is _extremely_ inconvenient.  A thorough
  > > removal can be done in steps too, and tags can help sort out the changes
  > > easily.  The unnecessary red tape just adds extra work for absolutely
  > > zero gain.
  > 
  > Can't imagine why it's so inconvenient.  Care to give some example of
  > the difficulties it adds?

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.  When updating you get unnecessary conflicts that need to be
resolved.  When working offline you can't cvs remove files.  If you cvs
remove files before tagging, the tag won't apply to that file.  And
probably more.  On the other hand the gain is inexistent.




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: VMS support
  2008-07-27 19:06                     ` Dan Nicolaescu
@ 2008-07-27 19:31                       ` Stefan Monnier
  2008-07-27 19:51                         ` Dan Nicolaescu
  0 siblings, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2008-07-27 19:31 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: Thien-Thi Nguyen, emacs-devel

> 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




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: VMS support
  2008-07-27 19:31                       ` Stefan Monnier
@ 2008-07-27 19:51                         ` Dan Nicolaescu
  2008-07-27 20:44                           ` Stefan Monnier
  2008-07-28  9:15                           ` Thien-Thi Nguyen
  0 siblings, 2 replies; 19+ messages in thread
From: Dan Nicolaescu @ 2008-07-27 19:51 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Thien-Thi Nguyen, emacs-devel

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

  > > 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

[snip] 
Yes there are solutions to all these, but they mean just more work, and
mean changing the normal work style, which is equivalent to more work.

  > > 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...).

That's what I've been saying, its absolutely _not_ minor.  And trading
requiring to do work now for _maybe_ avoiding work in the future when
_maybe_ someone _might_ pick up the code is a bad tradeoff.

So the question is, will you continue this policy?




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: VMS support
  2008-07-27 19:51                         ` Dan Nicolaescu
@ 2008-07-27 20:44                           ` Stefan Monnier
  2008-07-27 21:41                             ` Dan Nicolaescu
  2008-07-28  9:15                           ` Thien-Thi Nguyen
  1 sibling, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2008-07-27 20:44 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: Thien-Thi Nguyen, emacs-devel

> That's what I've been saying, its absolutely _not_ minor.

Keeping the ChangeLog on the side, as well as the list of files to `cvs
rm' seems like very minor annoyances.  Compared to the cost of finding
the parts of the code that uses Carbon, then finding the places that
refer to those places, ...  Maybe you don't think so because you'd
already done most of the work of finding the relevant places, but then
you just have a *perception* of a high marginal cost.

> And trading requiring to do work now for _maybe_ avoiding work in the
> future when _maybe_ someone _might_ pick up the code is
> a bad tradeoff.

Could be.  If you've ever been at the other end of the stick, you'll
know that the added work of extracting the relevant patches from a set
of interleaved patches can be excruciating.  Especially with CVS and its
lack of atomic commits.  So yes, the gain is only hypothetical, but is
potentially much higher than the cost.

> So the question is, will you continue this policy?

Yes.  As I said, if you don't want to do this job, then just leave the
old code in its place: we've been living with it for years, so it's
not like it's urgent to remove it.


        Stefan




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: VMS support
  2008-07-27 20:44                           ` Stefan Monnier
@ 2008-07-27 21:41                             ` Dan Nicolaescu
  0 siblings, 0 replies; 19+ messages in thread
From: Dan Nicolaescu @ 2008-07-27 21:41 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Thien-Thi Nguyen, emacs-devel

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

  > > That's what I've been saying, its absolutely _not_ minor.
  > 
  > Keeping the ChangeLog on the side, as well as the list of files to `cvs
  > rm' seems like very minor annoyances.  Compared to the cost of finding
  > the parts of the code that uses Carbon, then finding the places that
  > refer to those places, ...  Maybe you don't think so because you'd
  > already done most of the work of finding the relevant places, but then
  > you just have a *perception* of a high marginal cost.

Sorry, but repeating the same thing to someone that has the personal
practical experience of the things discussed is not exactly productive,
and obviously pointless.

  > > So the question is, will you continue this policy?
  > 
  > Yes.  As I said, if you don't want to do this job, then just leave the
  > old code in its place: we've been living with it for years, so it's
  > not like it's urgent to remove it.

Fine.  Dealing with silly, pointless red tape is not exactly the best
way to do volunteer work.




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: VMS support
  2008-07-27 19:51                         ` Dan Nicolaescu
  2008-07-27 20:44                           ` Stefan Monnier
@ 2008-07-28  9:15                           ` Thien-Thi Nguyen
  1 sibling, 0 replies; 19+ messages in thread
From: Thien-Thi Nguyen @ 2008-07-28  9:15 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: Stefan Monnier, emacs-devel

() Dan Nicolaescu <dann@ics.uci.edu>
() Sun, 27 Jul 2008 12:51:12 -0700

   [cvs problems]

Perhaps you can kill two birds w/ one stone and do the work under
another version control system, one that supports using a local
repo to incrementally commit, exercising the new repo-specific vc
code in the process.  Then, when everything is presentable, squash
the local changes into one commit for cvs.

That's more work, but you get some side-benefit as well.

thi




^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2008-07-28  9:15 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <87iquzmcxm.fsf@stupidchicken.com>
     [not found] ` <87d4l76ntu.fsf@ambire.localdomain>
2008-07-21 19:52   ` VMS support Chong Yidong
2008-07-23 10:27     ` Thien-Thi Nguyen
2008-07-23 20:05       ` Stefan Monnier
2008-07-24  7:44         ` Thien-Thi Nguyen
2008-07-24 13:59           ` Stefan Monnier
2008-07-24 16:55             ` Dan Nicolaescu
2008-07-24 19:58               ` Stefan Monnier
2008-07-27 18:41                 ` Dan Nicolaescu
2008-07-27 18:48                   ` Stefan Monnier
2008-07-27 19:06                     ` Dan Nicolaescu
2008-07-27 19:31                       ` Stefan Monnier
2008-07-27 19:51                         ` Dan Nicolaescu
2008-07-27 20:44                           ` Stefan Monnier
2008-07-27 21:41                             ` Dan Nicolaescu
2008-07-28  9:15                           ` Thien-Thi Nguyen
2008-07-24 17:34             ` Thien-Thi Nguyen
2008-07-24 20:00               ` Stefan Monnier
2008-07-24 20:40                 ` Thien-Thi Nguyen
2008-07-24  2:23       ` Richard M Stallman

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.