Another VC terminology change?

Another VC terminology change?

[Eric S. Raymond]

I note, in files.texi:

    The terms ``checkin'' and ``checkout'' are associated with file-based
    and locking-based systems and a bit archaic; nowadays those operations
    are usually called ``commit'' and ``update''.

Since I've had to take a big hammer to VC's terminology anyway to clean up the
inconsistencies Stefan pointed out, I'm thinking now might be a good time
for me to go further and change these.

The argument against, of course, is that users are accustomed to these
terms.  They're embedded in VC because when I originally wrote it SCCS
and RCS were the only games in town[1] and these are the terms they used.

The argument for is that 'commit' and 'update' are a better match for the
terms CVS introduced and every subsequent VCS we're interested in has pretty
much retained.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

[1] Actually, CVS was in use at a university somewhere, but it didn't hit 
the big time til a few years after I wrote VC.

Re: Another VC terminology change?

[Stefan Monnier]

>     The terms ``checkin'' and ``checkout'' are associated with file-based
>     and locking-based systems and a bit archaic; nowadays those operations
>     are usually called ``commit'' and ``update''.

> Since I've had to take a big hammer to VC's terminology anyway to clean up
> the inconsistencies Stefan pointed out, I'm thinking now might be a good
> time for me to go further and change these.

> The argument against, of course, is that users are accustomed to these
> terms.  They're embedded in VC because when I originally wrote it SCCS
> and RCS were the only games in town[1] and these are the terms they used.

> The argument for is that 'commit' and 'update' are a better match for the
> terms CVS introduced and every subsequent VCS we're interested in has
> pretty much retained.

Not about "checkout" which sometimes means "update" and sometimes "get".
But yes, "checkin" should be replaced by "commit".

This said, I don't know if we should change it only in the doc, or also in
the code, especially in the part of the code that interacts with the user
(i.e. commands) or the backends: I think it's important to make sure that
a single backend can work both with the new and the old VC.


        Stefan

Re: Another VC terminology change?

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> Not about "checkout" which sometimes means "update" and sometimes "get".

Yes, I'm aware of that problem.  I  need to do some comparative study 
of VCSes and think about their typologies some more before pursuing this.

> But yes, "checkin" should be replaced by "commit".
> 
> This said, I don't know if we should change it only in the doc, or also in
> the code, especially in the part of the code that interacts with the user
> (i.e. commands) or the backends: I think it's important to make sure that
> a single backend can work both with the new and the old VC.

That compatibility is gone beyond retrieval.  It was already doomed when
I moved the backends to taking fileset args, and I added another
layer of impossible with the version -> revision terminology change.

So if we're going to do this change at all, it might as well be in docs and
code both.  Maintaining consistency will save us problems later.

But I need to some more thinking before moveing on this.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Another VC terminology change?

[Stefan Monnier]

>> Not about "checkout" which sometimes means "update" and sometimes "get".
     ^^^
    sure    [sorry 'bout that]

>> But yes, "checkin" should be replaced by "commit".
>> This said, I don't know if we should change it only in the doc, or also in
>> the code, especially in the part of the code that interacts with the user
>> (i.e. commands) or the backends: I think it's important to make sure that
>> a single backend can work both with the new and the old VC.

> That compatibility is gone beyond retrieval.  It was already doomed when
> I moved the backends to taking fileset args,

It worked fine back then.  The backends just had to be careful to accept
both a list or a string and to treat a string as a list of 1 element.

> and I added another layer of impossible with the version -> revision
> terminology change.

We can (and maybe should) provide backward compatibility aliases to
handle that.

> So if we're going to do this change at all, it might as well be in docs and
> code both.  Maintaining consistency will save us problems later.

OK.  As said, we can (and maybe should) provide backward
compatibility aliases.


        Stefan

Re: Another VC terminology change?

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> OK.  As said, we can (and maybe should) provide backward
> compatibility aliases.

Possible...but I severely doubt that API has any clients outside the
Emacs libraries, or I'd have heard of it by now.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Another VC terminology change?

[Stefan Monnier]

>> OK.  As said, we can (and maybe should) provide backward
>> compatibility aliases.

> Possible...but I severely doubt that API has any clients outside the
> Emacs libraries, or I'd have heard of it by now.

I'm concerned about new clients (e.g. Codeville, OpenCM, svk, ...).


        Stefan

Re: Another VC terminology change?

[Dan Nicolaescu]

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

  > Not about "checkout" which sometimes means "update" and sometimes "get".

Speaking of "update", vc-update needs to be rethought a bit.
Mercurial, bzr and git (maybe other systems too) don't seem to want to
do merges based on a file, but on changesets.
What should we do about that?

Re: Another VC terminology change?

[Stefan Monnier]

>> Not about "checkout" which sometimes means "update" and sometimes "get".
> Speaking of "update", vc-update needs to be rethought a bit.
> Mercurial, bzr and git (maybe other systems too) don't seem to want to
> do merges based on a file, but on changesets.
> What should we do about that?

Those backends should simply signal an error if requested to update
something less than the whole tree.


        Stefan

Re: Another VC terminology change?

[Dan Nicolaescu]

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

  > >> Not about "checkout" which sometimes means "update" and sometimes "get".
  > > Speaking of "update", vc-update needs to be rethought a bit.
  > > Mercurial, bzr and git (maybe other systems too) don't seem to want to
  > > do merges based on a file, but on changesets.
  > > What should we do about that?
  > 
  > Those backends should simply signal an error if requested to update
  > something less than the whole tree.

So what would the UI be for that?
vc-BACKEND-merge-news currently has a `file' parameter. 
Should backends check if it is a directory, and then run the merge
command? 
Who is responsible for updating all the buffers for files that have
been changed by the merge?

Re: Another VC terminology change?

[Stefan Monnier]

>> >> Not about "checkout" which sometimes means "update" and sometimes "get".
>> > Speaking of "update", vc-update needs to be rethought a bit.
>> > Mercurial, bzr and git (maybe other systems too) don't seem to want to
>> > do merges based on a file, but on changesets.
>> > What should we do about that?
>> 
>> Those backends should simply signal an error if requested to update
>> something less than the whole tree.

> So what would the UI be for that?

You mean API rather than UI, right?

> vc-BACKEND-merge-news currently has a `file' parameter.
> Should backends check if it is a directory, and then run the merge
> command?

Those backends which can only perform such operations on whole trees, should
(obviously) check that the parameter refers to a whole tree and signal an
error if it doesn't.

> Who is responsible for updating all the buffers for files that have
> been changed by the merge?

VC.  The backend should return a list of files that were updated (maybe
together with their new status?), and then vc.el will be in charge of
reverting the corresponding buffers (and update the relevant vc-dired
buffers, ...).


        Stefan

Re: Another VC terminology change?

[Dan Nicolaescu]

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

  > >> >> Not about "checkout" which sometimes means "update" and sometimes "get".
  > >> > Speaking of "update", vc-update needs to be rethought a bit.
  > >> > Mercurial, bzr and git (maybe other systems too) don't seem to want to
  > >> > do merges based on a file, but on changesets.
  > >> > What should we do about that?
  > >> 
  > >> Those backends should simply signal an error if requested to update
  > >> something less than the whole tree.
  > 
  > > So what would the UI be for that?
  > 
  > You mean API rather than UI, right?

I mean UI. How does the user request a merge on such a VCS?  Using
"C-x v +" from any VC managed file?  Should it then warn that the
whole tree is getting merged?

  > > vc-BACKEND-merge-news currently has a `file' parameter.
  > > Should backends check if it is a directory, and then run the merge
  > > command?
  > 
  > Those backends which can only perform such operations on whole trees, should
  > (obviously) check that the parameter refers to a whole tree and signal an
  > error if it doesn't.
  > 
  > > Who is responsible for updating all the buffers for files that have
  > > been changed by the merge?
  > 
  > VC.  The backend should return a list of files that were updated (maybe
  > together with their new status?), and then vc.el will be in charge of
  > reverting the corresponding buffers (and update the relevant vc-dired
  > buffers, ...).

What happens if there are conflicts in files that are not opened?
Should VC show pop a vc-dired window and show them?

Re: Another VC terminology change?

[Stefan Monnier]

>> You mean API rather than UI, right?
> I mean UI. How does the user request a merge on such a VCS?  Using
> "C-x v +" from any VC managed file?  Should it then warn that the
> whole tree is getting merged?

No: it needs to do it from a place where he can specify the right fileset,
i.e. from vc-dired (or maybe from just `dired' depending on how this works).

> What happens if there are conflicts in files that are not opened?
> Should VC show pop a vc-dired window and show them?

The Lisp of possible features is open ended, but if the command was run from
a vc-dired buffer, there's nothing special to do, which is a good reason to
request that such commands be run from a vc-dired buffer.


        Stefan

Re: Another VC terminology change?

[Dan Nicolaescu]

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

  > >> You mean API rather than UI, right?
  > > I mean UI. How does the user request a merge on such a VCS?  Using
  > > "C-x v +" from any VC managed file?  Should it then warn that the
  > > whole tree is getting merged?
  > 
  > No: it needs to do it from a place where he can specify the right fileset,
  > i.e. from vc-dired (or maybe from just `dired' depending on how this works).

If we go that way, then VC would need a way to know this. It would
need order to issue meaningful error messages when the user tries to
use C-x v + from a buffer managed by a VCS that does not support per
file merging.

Re: Another VC terminology change?

[Stefan Monnier]

>> >> You mean API rather than UI, right?
>> > I mean UI. How does the user request a merge on such a VCS?  Using
>> > "C-x v +" from any VC managed file?  Should it then warn that the
>> > whole tree is getting merged?
>> 
>> No: it needs to do it from a place where he can specify the right fileset,
>> i.e. from vc-dired (or maybe from just `dired' depending on how this works).

> If we go that way, then VC would need a way to know this. It would
> need order to issue meaningful error messages when the user tries to
> use C-x v + from a buffer managed by a VCS that does not support per
> file merging.

Why?  The user will do C-x v + from the file buffer, which vc.el will pass
on to the backend and the backend will signal an error.
I see no problem,


        Stefan

Re: Another VC terminology change?

[Richard Stallman]

	The terms ``checkin'' and ``checkout'' are associated with file-based
	and locking-based systems and a bit archaic; nowadays those operations
	are usually called ``commit'' and ``update''.

    Since I've had to take a big hammer to VC's terminology anyway to clean up the
    inconsistencies Stefan pointed out, I'm thinking now might be a good time
    for me to go further and change these.

Please deal with the fileset problem before tackling other issues.

Re: Another VC terminology change?

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
> Please deal with the fileset problem before tackling other issues.

Perhaps you missed my longer email on that issue.  I don't see a problem 
there; in fact I would actively resist inventing a new term because I
think fuileset means the same thing in both places.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Another VC terminology change?

[Eli Zaretskii]

> Date: Thu, 11 Oct 2007 13:50:16 -0400
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: emacs-devel@gnu.org
> 
> Richard Stallman <rms@gnu.org>:
> > Please deal with the fileset problem before tackling other issues.
> 
> Perhaps you missed my longer email on that issue.

RMS reads email with a 24-hour delay, on average.

Re: Another VC terminology change?

[Richard Stallman]

    Perhaps you missed my longer email on that issue.  I don't see a problem 
    there; in fact I would actively resist inventing a new term because I
    think fuileset means the same thing in both places.

I wish that were true, but it isn't.  In VC, a fileset is the
set of files marked in a dired buffer.  This is a transitory set.
In the Filesets node, filesets are semipermanent entities
that you define with filesets-add-buffer or other mechanisms.

It will be natural for the reader to suppose that "fileset" refers to
the same sort of thing everywhere it is used in the manual.
But it doesn't, and that is a serious problem.

We cannot leave things this way.

Re: Another VC terminology change?

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> I wish that were true, but it isn't.  In VC, a fileset is the
> set of files marked in a dired buffer.  This is a transitory set.
> In the Filesets node, filesets are semipermanent entities
> that you define with filesets-add-buffer or other mechanisms.

I'd never heard of  the latter.  Does anyone use it?  Is it new?

-Miles

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

Re: Another VC terminology change?

[Richard Stallman]

    > In the Filesets node, filesets are semipermanent entities
    > that you define with filesets-add-buffer or other mechanisms.

    I'd never heard of  the latter.  Does anyone use it?  Is it new?

filesets.el was added in 2005.

I am not entirely happy with it.  It seems that such a feature ought
to be better integrated with the rest of Emacs than this actually is.

Re: Another VC terminology change?

[Juri Linkov]

>     > In the Filesets node, filesets are semipermanent entities
>     > that you define with filesets-add-buffer or other mechanisms.
>
>     I'd never heard of  the latter.  Does anyone use it?  Is it new?
>
> filesets.el was added in 2005.
>
> I am not entirely happy with it.  It seems that such a feature ought
> to be better integrated with the rest of Emacs than this actually is.

Isn't filesets.el similar by its functionality to the recently proposed
project.el?  It seems "project" is a better name for it.

As for the VC terminology, in contexts where the term "filesets" is
ambiguous, it is possible to disambiguate it by using "VC filesets".

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Another VC terminology change?

[Richard Stallman]

    Isn't filesets.el similar by its functionality to the recently proposed
    project.el?

Isn't project.el the facility that lets you specify local bindings for
a directory?

fileset.el does a lot more than that.  They are not similar.

    As for the VC terminology, in contexts where the term "filesets" is
    ambiguous, it is possible to disambiguate it by using "VC filesets".

That is better than what we have now, but still rather clumsy,
so it is not a good solution.  We need a better one.

Re: Another VC terminology change?

[Stefan Monnier]

>     Isn't filesets.el similar by its functionality to the recently proposed
>     project.el?

> Isn't project.el the facility that lets you specify local bindings for
> a directory?

> fileset.el does a lot more than that.  They are not similar.

>     As for the VC terminology, in contexts where the term "filesets" is
>     ambiguous, it is possible to disambiguate it by using "VC filesets".

> That is better than what we have now, but still rather clumsy,
> so it is not a good solution.  We need a better one.

I think we don't want to restrict the term "file set" to the specific one
corresponding to filesets.el.  Instead, we want to keep it as a fairly
abstract concept, with uses in filesets and VC and other packages
(project.el comes to mind although it doesn't refer to it explicitly).

So, I'd distinguish between "file set" as the general concept, and "VC
fileset" and (filesets.el's) "Fileset" as specific instantiations.


        Stefan

Re: Another VC terminology change?

[Eric S. Raymond]

Stefan Monnier <monnier@IRO.UMontreal.CA>:
> I think we don't want to restrict the term "file set" to the specific one
> corresponding to filesets.el.  Instead, we want to keep it as a fairly
> abstract concept, with uses in filesets and VC and other packages
> (project.el comes to mind although it doesn't refer to it explicitly).
> 
> So, I'd distinguish between "file set" as the general concept, and "VC
> fileset" and (filesets.el's) "Fileset" as specific instantiations.

That is exactly my position.  Well put,
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Another VC terminology change?

[Richard Stallman]

    I think we don't want to restrict the term "file set" to the specific one
    corresponding to filesets.el.  Instead, we want to keep it as a fairly
    abstract concept, with uses in filesets and VC and other packages
    (project.el comes to mind although it doesn't refer to it explicitly).

    So, I'd distinguish between "file set" as the general concept, and "VC
    fileset" and (filesets.el's) "Fileset" as specific instantiations.

In principle it could work to make "file set" a general term, if we
have two suitable specific terms for the two specific concepts used in
these two features.  But that proposal has trouble in the details:
if we use the terms "VC fileset" and "fileset", it sounds like the
former is a special case of the latter.  

Can you modify it to solve the problem?

Re: Another VC terminology change?

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
> In principle it could work to make "file set" a general term, if we
> have two suitable specific terms for the two specific concepts used in
> these two features.  But that proposal has trouble in the details:
> if we use the terms "VC fileset" and "fileset", it sounds like the
> former is a special case of the latter.  
> 
> Can you modify it to solve the problem?

That's easy.  The real difference isn't between "used in VC" and elsewhere,
it's in the lifetime and source of the fileset.

A few additions to the manual can address this.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Another VC terminology change?

[Richard Stallman]

      But that proposal has trouble in the details:
    > if we use the terms "VC fileset" and "fileset", it sounds like the
    > former is a special case of the latter.  
    > 
    > Can you modify it to solve the problem?

    That's easy.  The real difference isn't between "used in VC" and elsewhere,
    it's in the lifetime and source of the fileset.

I think that would be a confusing way to describe the situation.
These two "kinds of filesets" are different data types, with totally
different commands.

Re: Another VC terminology change?

[Eli Zaretskii]

> Date: Thu, 11 Oct 2007 10:30:05 -0400
> From: "Eric S. Raymond" <esr@thyrsus.com>
> 
>     The terms ``checkin'' and ``checkout'' are associated with file-based
>     and locking-based systems and a bit archaic; nowadays those operations
>     are usually called ``commit'' and ``update''.
> 
> Since I've had to take a big hammer to VC's terminology anyway to clean up the
> inconsistencies Stefan pointed out, I'm thinking now might be a good time
> for me to go further and change these.
> 
> The argument against, of course, is that users are accustomed to these
> terms.  They're embedded in VC because when I originally wrote it SCCS
> and RCS were the only games in town[1] and these are the terms they used.
> 
> The argument for is that 'commit' and 'update' are a better match for the
> terms CVS introduced and every subsequent VCS we're interested in has pretty
> much retained.

How about making the replacement, but adding a footnote saying that
some older VCS backends call these operations ``checkin'' and
``checkout''?