VC filesets

VC filesets

[Chong Yidong]

I'm currently updating the Emacs manual, and I need someone to clarify
how VC filesets work in the new VC.

If the current buffer is in a version controlled file, does the default
VC fileset ALWAYS consist of just that one file?  Or can it consist of
other files, marked out in another VC directory buffer (assuming that VC
directory buffer is not the current buffer)?

If someone has experience using the new VC on distributed version
control systems, please reply.  Thanks.

Re: VC filesets

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > I'm currently updating the Emacs manual, and I need someone to clarify
  > how VC filesets work in the new VC.
  > 
  > If the current buffer is in a version controlled file, does the default
  > VC fileset ALWAYS consist of just that one file?  

Yep.  
(in case you want to look at the details, the function that deals with
this is vc-deduce-fileset).

Re: VC filesets

[Glenn Morris]

Chong Yidong wrote:

> I'm currently updating the Emacs manual, and I need someone to clarify
> how VC filesets work in the new VC.

On this subject, it's unfortunate that VC now uses the term "fileset"
extensively, with a totally different meaning to the pre-existing
"filesets.el" package; but I don't have a solution.

RE: VC filesets

[Drew Adams]

> On this subject, it's unfortunate that VC now uses the term "fileset"
> extensively, with a totally different meaning to the pre-existing
> "filesets.el" package; but I don't have a solution.

I know nothing about VC filesets, but I agree about the problem - and I too
don't have a solution. ;-)

I think the problem comes from the adoption of "fileset" by filesets.el - that
term is too general as a name for the specific feature that the library
implements.

There was nothing wrong with that characterization by filesets.el at the time.
It's just that the term is intrinsically so general that it naturally leads to
verbal gymnastics to avoid confusion with the limited meaning it has taken on in
Emacs.

As another illustration, Icicles supports Emacs filesets but it also supports
other kinds of saved sets of file names. The Icicles doc refers to the latter in
just that roundabout way, because "fileset" has been given a narrow meaning by
Emacs.

I'm not proposing anything here - just adding another anecdote about the
unfortunate terminology situation.

Similar things could be said about other features - bookmarks, for instance.
Googling or searching the Emacs wiki will show that there are other packages
that provide bookmarking features, but calling those features "bookmarks" leads
to confusion in cases where they are incompatible with the bookmarks of
bookmarks.el.

I doubt that there is a good general solution to problems such as this.
Proactively we could try to use more specific terms for new features - or to
invent new terms, instead of eagerly adopting very general existing terms.

There probably is a natural tendency, unfortunately, for a feature inventor to
characterize the feature in the most general terms. Bookmarking (or tabs or ...)
in Emacs means just this feature...

Another thing that might help a little bit (but not much) would be to choose a
different name for the library itself, if a general name is chosen for the
feature.

It's pretty clear, for example, if you speak of "Bm bookmarks", or "Info
breadcrumbs", or "Tabbar tabs". It's less clear if you have to speak of
"Bookmarks bookmarks", or "Breadcrumbs breadcrumbs", or "Tabs tabs" (for a
fictitious library tabs.el).

Re: VC filesets

[Richard M. Stallman]

The idea was that filesets.el would be a general facility for file sets
and that we would make other things work with it.

RE: VC filesets

[Drew Adams]

> The idea was that filesets.el would be a general facility for 
> file sets and that we would make other things work with it.

Yes, I realize that. But it is not that general. And things haven't really
worked out that way. And regardless of what one might think of that particular
example, the general terminology issues that were raised remain.

It doesn't matter, for example, that bookmarks.el *is* quite general and could
be extended to include things that might be found in other "bookmarks" libraries
available here and there. Independent libraries get developed with different or
similar features - or even virtually identical features that are implemented
differently. In many cases they will always remain separate, rather than being
incorporated (into bookmarks.el for example).

The problems I raised are (only) about terminology, not about implementation,
features, or packaging. It's about how to talk about features, not about how to
integrate or assimilate them.

Using more specific names can help avoid some of the problems. Using file names
that are different from general feature names can help too. But I don't see a
general solution to the terminology problems.

In the case Glenn initially raised, VC filesets, presumably a solution could be
found, because VC filesets and filesets.el filesets are both part of Emacs. I
take his observation as a suggestion that VC filesets should be called something
else. That would take care of this particular occurrence of the problem.

Or perhaps, following your remark above, VC filesets should be somehow
integrated with filesets.el filesets, since the latter feature is the intended
"general facility for file sets". I can't speak to that, knowing nothing about
VC filesets.

Re: VC filesets

[Chong Yidong]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>   > I'm currently updating the Emacs manual, and I need someone to clarify
>   > how VC filesets work in the new VC.
>   > 
>   > If the current buffer is in a version controlled file, does the default
>   > VC fileset ALWAYS consist of just that one file?  
>
> Yep.  
> (in case you want to look at the details, the function that deals with
> this is vc-deduce-fileset).

That's what I thought.

But in that case, what's the meaning of this paragraph in files.texi?
It seems to be saying that `C-x v v' automatically DTRT outside of VC
dir mode by including the file in a changeset.

     If you are accustomed to earlier versions of VC, the change in
  behavior you will notice is in the directory mode.  Other than
  @kbd{C-x v v}, most VC-mode commands once operated on only one file
  selected by the line the cursor is on.  The change in the behavior of
  @kbd{C-x v v} outside VC Directory Mode is more subtle.  Formerly it
  operated in parallel on all marked files, but did not pass them to the
  version-control backends as a group.  Now it does, which enables VC to
  drive changeset-based version-control systems.

Re: VC filesets

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > Chong Yidong <cyd@stupidchicken.com> writes:
  > >
  > >   > I'm currently updating the Emacs manual, and I need someone to clarify
  > >   > how VC filesets work in the new VC.
  > >   > 
  > >   > If the current buffer is in a version controlled file, does the default
  > >   > VC fileset ALWAYS consist of just that one file?  
  > >
  > > Yep.  
  > > (in case you want to look at the details, the function that deals with
  > > this is vc-deduce-fileset).
  > 
  > That's what I thought.
  > 
  > But in that case, what's the meaning of this paragraph in files.texi?

Well, your question referred strictly to "the current buffer is in a
version controlled file".

  > It seems to be saying that `C-x v v' automatically DTRT outside of VC
  > dir mode by including the file in a changeset.
  > 
  >      If you are accustomed to earlier versions of VC, the change in
  >   behavior you will notice is in the directory mode.  Other than

IMHO this should not be in the texi docs, the difference between old and
new versions belongs in NEWS, "new" gets old too fast in the docs.

  >   @kbd{C-x v v}, most VC-mode commands once operated on only one file
  >   selected by the line the cursor is on.  The change in the behavior of
  >   @kbd{C-x v v} outside VC Directory Mode is more subtle.  Formerly it
  >   operated in parallel on all marked files, but did not pass them to the
  >   version-control backends as a group.  Now it does, which enables VC to
  >   drive changeset-based version-control systems.

Maybe it wants to talk about this:

Note that if you do 
C-x v d
mark 2 files in the 'edited state, then do C-x v l
then in the log view buffer you do C-x v = you get the diff for the 2
files that were marked.
Or if you do C-x v v from the diff buffer, it will check in the 2 marked
files... 


This part:

  > Formerly it operated in parallel on all marked files, but did not
  > pass them to the version-control backends as a group.

probably wants to say that before in vc-directory you could select
multiple files, and check them in, but they were checked in one file at
a time, instead of as a group in a single command.  Just guessing
here...