vc-status vs pcl-cvs

vc-status vs pcl-cvs

[Sam Steingold]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am trying to switch from pcl-cvs to vc-status to use the same
interface for cvs and hg.

I have the following problems though:

1. commit is in foreground, not background.

2. there is no way to update the whole directory (O in pcl-cvs runs
cvs-mode-update which runs "cvs up" on the selection or the whole
directory).

3. lines like "DIRECTORY            ./" - what are they for? how do I
get rid of them?

thanks!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIRbogPp1Qsf2qnMcRAtB5AJ9kUpk3mwxdCgslL6unfeBJH1N4DQCeOy34
Mpgoczi/bye33ANyfHR9K2M=
=A9JA
-----END PGP SIGNATURE-----

Re: vc-status vs pcl-cvs

[Stefan Monnier]

> I am trying to switch from pcl-cvs to vc-status to use the same
> interface for cvs and hg.

> I have the following problems though:

> 1. commit is in foreground, not background.

Yes, patches welcome.

> 2. there is no way to update the whole directory (O in pcl-cvs runs
> cvs-mode-update which runs "cvs up" on the selection or the whole
> directory).

Indeed, patches welcome.

> 3. lines like "DIRECTORY            ./" - what are they for? how do I
> get rid of them?

They're there so you can select the whole directory.  PCL-CVS has them
as well (tho they were configurable so you may have disabled them).

vc-dir (previous "vc-status") is very much a work in progress, as you've seen.


        Stefan

Re: vc-status vs pcl-cvs

[Nick Roberts]

 > vc-dir (previous "vc-status") is very much a work in progress, as you've
 > seen.

In that case, do you think premature to remove vc-directory which was better
at doing some of the things vc-dir should do?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: vc-status vs pcl-cvs

[Stefan Monnier]

>> vc-dir (previous "vc-status") is very much a work in progress, as you've
>> seen.
> In that case, do you think premature to remove vc-directory which was better
> at doing some of the things vc-dir should do?

AFAIK, it has the same "commit in foreground" and "no way to update the
whole direcrory" problem.  VC-dir is missing some features, but which
ones (other than the obvious ones from dired which probably won't be
added to vc-dir anyway) were present in vc-dired?


        Stefan


PS: Has vc-dired been removed already?

Re: vc-status vs pcl-cvs

[Nick Roberts]

 > > In that case, do you think [it was] premature to remove vc-directory which
 > > was better at doing some of the things vc-dir should do?
 > 
 > AFAIK, it has the same "commit in foreground" and "no way to update the
 > whole direcrory" problem.  VC-dir is missing some features, but which
 > ones (other than the obvious ones from dired which probably won't be
 > added to vc-dir anyway) were present in vc-dired?

vc-dir always needs the repository (even when vc-stay-local is t), mouse-2
doesn't visit files, vc-dir isn't documented (but vc-directory is)...

 > 
 >         Stefan
 > 
 > 
 > PS: Has vc-dired been removed already?

Yes:

2008-05-07  Eric S. Raymond  <esr@snark.thyrsus.com>

	* vc.el, vc-dispatcher.el: VC-Dired support removed.


Sometimes removing a old feature might encourage people to use the new one
but other times it might just make people use an old version of Emacs.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: vc-status vs pcl-cvs

[Dan Nicolaescu]

Nick Roberts <nickrob@snap.net.nz> writes:

  >  > > In that case, do you think [it was] premature to remove vc-directory which
  >  > > was better at doing some of the things vc-dir should do?
  >  > 
  >  > AFAIK, it has the same "commit in foreground" and "no way to update the
  >  > whole direcrory" problem.  VC-dir is missing some features, but which
  >  > ones (other than the obvious ones from dired which probably won't be
  >  > added to vc-dir anyway) were present in vc-dired?
  > 
  > vc-dir always needs the repository (even when vc-stay-local is t), 

This would need to be implemented in specific backends (only CVS and svn
care about it).  And it's rather easy: in vc-*-dir-status can use
something like vc-rcs-dir-status.  Patches are welcome.
(IMHO this is not very useful, but if people want it...)

  > mouse-2 doesn't visit files, 

You can talk to the person that implemented the current binding to
change it.

  > vc-dir isn't documented (but vc-directory is)...

Patches are welcome.

Re: vc-status vs pcl-cvs

[Stefan Monnier]

>> > > In that case, do you think [it was] premature to remove vc-directory which
>> > > was better at doing some of the things vc-dir should do?
>> > 
>> > AFAIK, it has the same "commit in foreground" and "no way to update the
>> > whole direcrory" problem.  VC-dir is missing some features, but which
>> > ones (other than the obvious ones from dired which probably won't be
>> > added to vc-dir anyway) were present in vc-dired?
>> 
>> vc-dir always needs the repository (even when vc-stay-local is t), 

> This would need to be implemented in specific backends (only CVS and svn
> care about it).  And it's rather easy: in vc-*-dir-status can use
> something like vc-rcs-dir-status.  Patches are welcome.
> (IMHO this is not very useful, but if people want it...)

I disagree.  The "stay-local" should be the default.  It is tremendously
useful (think of the case where you're not connected to your
repository).  The non-stay-local behavior is the one whose usefulness is
debatable (after all, most new VCS don't bother offering a clean
equivalent).


        Stefan

Re: vc-status vs pcl-cvs

[Dan Nicolaescu]

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

  > >> > > In that case, do you think [it was] premature to remove vc-directory which
  > >> > > was better at doing some of the things vc-dir should do?
  > >> > 
  > >> > AFAIK, it has the same "commit in foreground" and "no way to update the
  > >> > whole direcrory" problem.  VC-dir is missing some features, but which
  > >> > ones (other than the obvious ones from dired which probably won't be
  > >> > added to vc-dir anyway) were present in vc-dired?
  > >> 
  > >> vc-dir always needs the repository (even when vc-stay-local is t), 
  > 
  > > This would need to be implemented in specific backends (only CVS and svn
  > > care about it).  And it's rather easy: in vc-*-dir-status can use
  > > something like vc-rcs-dir-status.  Patches are welcome.
  > > (IMHO this is not very useful, but if people want it...)
  > 
  > I disagree.  The "stay-local" should be the default.  It is tremendously
  > useful (think of the case where you're not connected to your
  > repository).  The non-stay-local behavior is the one whose usefulness is
  > debatable (after all, most new VCS don't bother offering a clean
  > equivalent).

So that means you'd want vc-dir to work differently by default than
cvs-status?  That would be surprising for most users.
In the case of being disconnected, vc-dir can only show you the file
states, if they are edited or not, you can't do diff/log/annotate/commit
etc.  That's the reason I think it's not very useful.

Now, to implement this stuff vc-cvs-dir-status just needs to be changed
to do 
(if vc-cvs-stay-local-p
    THE_CODE_FROM-vc-rcs-dir-status
  THE_CURRENT_CODE)

(vc-rcs-dir-status has issues as noted in the comments and in the vc.el:Todo)

Re: vc-status vs pcl-cvs

[Stefan Monnier]

> So that means you'd want vc-dir to work differently by default than
> cvs-status?

Of course.  `cvs-examine' and `cvs-status' are there only for
historical reasons.  *THE* entry point to PCL-CVS is cvs-quickdir.

> That would be surprising for most users.  In the case of being
> disconnected, vc-dir can only show you the file states, if they are
> edited or not,

Which is indeed all the info you'll ever get from all other VCSes.
Their `vc-dir' command will never tell you "needs-update" either.

> you can't do diff/log/annotate/commit etc.

That's a limitation of the underlying backend.  Not much we can do about it.

> That's the reason I think it's not very useful.

> Now, to implement this stuff vc-cvs-dir-status just needs to be changed
> to do
> (if vc-cvs-stay-local-p
>     THE_CODE_FROM-vc-rcs-dir-status
>   THE_CURRENT_CODE)

Actually it might be better off using cvs-fileinfo-from-entries.
The only shortcoming of cvs-fileinfo-from-entries is that it won't show
you the "unknown" files (files that are neither ignored nor under CVS
control).


        Stefan

Re: vc-status vs pcl-cvs

[Dan Nicolaescu]

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

  > > So that means you'd want vc-dir to work differently by default than
  > > cvs-status?
  > 
  > Of course.  `cvs-examine' and `cvs-status' are there only for
  > historical reasons.  *THE* entry point to PCL-CVS is cvs-quickdir.

How many people actually know about that/use it?  (I certainly never
heard of it, and it's not in the menu or etc/NEWS so it's not
obvious or easy to find).

  > > That would be surprising for most users.  In the case of being
  > > disconnected, vc-dir can only show you the file states, if they are
  > > edited or not,
  > 
  > Which is indeed all the info you'll ever get from all other VCSes.
  > Their `vc-dir' command will never tell you "needs-update" either.

But the state those backends show in vc-dir is accurate, and you can
just check things in without a problem.  If things go the way you are
proposing, how do you get the up to date state so you can actually check
in your changes?  Another command?  I'd rather not have the users jump
through another hoop by default.

  > > Now, to implement this stuff vc-cvs-dir-status just needs to be changed
  > > to do
  > > (if vc-cvs-stay-local-p
  > >     THE_CODE_FROM-vc-rcs-dir-status
  > >   THE_CURRENT_CODE)
  > 
  > Actually it might be better off using cvs-fileinfo-from-entries.
  > The only shortcoming of cvs-fileinfo-from-entries is that it won't show
  > you the "unknown" files (files that are neither ignored nor under CVS
  > control).

If someone cares enough about this, there's enough information to
implement it.

Re: vc-status vs pcl-cvs

[Nick Roberts]

 >   > > Now, to implement this stuff vc-cvs-dir-status just needs to be changed
 >   > > to do
 >   > > (if vc-cvs-stay-local-p
 >   > >     THE_CODE_FROM-vc-rcs-dir-status
 >   > >   THE_CURRENT_CODE)
 >   > 
 >   > Actually it might be better off using cvs-fileinfo-from-entries.
 >   > The only shortcoming of cvs-fileinfo-from-entries is that it won't show
 >   > you the "unknown" files (files that are neither ignored nor under CVS
 >   > control).
 > 
 > If someone cares enough about this, there's enough information to
 > implement it.

We're not talking about adding this feature but not taking it away.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: vc-status vs pcl-cvs

[Stefan Monnier]

>> Which is indeed all the info you'll ever get from all other VCSes.
>> Their `vc-dir' command will never tell you "needs-update" either.

> But the state those backends show in vc-dir is accurate, and you can
> just check things in without a problem.

Not necessarily.  With Bazaar, if you do a "checkout"
(i.e. a bound-branch: your local branch is bound to some other branch;
commits go to both places), then bzr commit may fail if you haven't
first updated your local branch to the latest revision on the
upstream branch.

Of course, with CVS the problem is also present if you use cvs-status:
the returned state may be "accurate" when you receive it, but it can
change before you do the commit.

> If things go the way you are proposing, how do you get the up to date
> state so you can actually check in your changes?  Another command?

Yes, a command we absolutely need anyway: vc-pull.


        Stefan

Re: vc-status vs pcl-cvs

[Dan Nicolaescu]

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

  > >> Which is indeed all the info you'll ever get from all other VCSes.
  > >> Their `vc-dir' command will never tell you "needs-update" either.
  > 
  > > But the state those backends show in vc-dir is accurate, and you can
  > > just check things in without a problem.
  > 
  > Not necessarily.  With Bazaar, if you do a "checkout"
  > (i.e. a bound-branch: your local branch is bound to some other branch;
  > commits go to both places), then bzr commit may fail if you haven't
  > first updated your local branch to the latest revision on the
  > upstream branch.
  > 
  > Of course, with CVS the problem is also present if you use cvs-status:
  > the returned state may be "accurate" when you receive it, but it can
  > change before you do the commit.

Well, that's always the case for any shared system, isn't it?  So
there's no real reason to mix that in this discussion.

  > > If things go the way you are proposing, how do you get the up to date
  > > state so you can actually check in your changes?  Another command?
  > 
  > Yes, a command we absolutely need anyway: vc-pull.

We do need the vc-pull command, but we don't need it for CVS _by default_.  
Sure, it could be used for CVS, but that is not the normal workflow for
CVS, so it would just confuse our users.   And while the implementation
of vc-cvs-stay-local is trivial, vc-pull is not.

Re: vc-status vs pcl-cvs

[Sam Steingold]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan Nicolaescu wrote:
| Stefan Monnier <monnier@iro.umontreal.ca> writes:
|   > Yes, a command we absolutely need anyway: vc-pull.

Yay!

| We do need the vc-pull command, but we don't need it for CVS _by
default_.
| Sure, it could be used for CVS, but that is not the normal workflow for
| CVS, so it would just confuse our users.   And while the implementation
| of vc-cvs-stay-local is trivial, vc-pull is not.

Now I am confused.
I thought that vc-pull would do
cvs up
hg pull -u (and if necessary hg merge && hg ci -m merge)
&c, i.e., sync my local tree with the remote one.
this is what I get when I hit "O" in pcl-cvs and
this is what I am sorely missing in vc-dir.
this is a part of my normal workflow in both hg and cvs because this is
what I have to do before commit (in cvs) or push (in hg).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFISBUfPp1Qsf2qnMcRArQ/AKCtVQjYMotcsh84346nhXcaC8oJEQCeIyZh
DbkFPnxHCelRvMLLoB3se34=
=013U
-----END PGP SIGNATURE-----

Re: vc-status vs pcl-cvs

[Stefan Monnier]

>> Yes, a command we absolutely need anyway: vc-pull.
> We do need the vc-pull command, but we don't need it for CVS _by default_.  

Why not?  What else is there?


        Stefan

Re: vc-status vs pcl-cvs

[Dan Nicolaescu]

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

  > >> Yes, a command we absolutely need anyway: vc-pull.
  > > We do need the vc-pull command, but we don't need it for CVS _by default_.  
  > 
  > Why not?  What else is there?

Truncating the discussion in this way with deleting too much context
does not help the dialog... 
vc-pull is needed in general, but forcing it to be used by default by
avoiding the use of cvs status does not seem to be a good idea.
Anyway we'll see what users actually think if someone actually
implements this stuff.

Re: vc-status vs pcl-cvs

[Sam Steingold]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Monnier wrote:
| The "stay-local" should be the default.  It is tremendously
| useful (think of the case where you're not connected to your
| repository).  The non-stay-local behavior is the one whose usefulness is
| debatable (after all, most new VCS don't bother offering a clean
| equivalent).

I disagree. I think "stay-local" is useful only when you not connected
to the internet, and this is a very rare condition these days.
in general, the value of stay-local should be detected automatically by
a ping.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIRtsCPp1Qsf2qnMcRAuKEAKClCV6HJQYbH3NiMntGViKBAqiUCQCgg0Ln
4oBWDp8jmFEbkNEXOooQUSA=
=dHMv
-----END PGP SIGNATURE-----

Re: vc-status vs pcl-cvs

[Stefan Monnier]

> I disagree.  I think "stay-local" is useful only when you not connected
> to the internet,

Why?  The only difference is that it'll show you some "needs-update".
No other backend ever does that, and nobody ever cmplained about them.

Of course, there (c|sh)ould be a command (let's call it vc-pull-dry-run)
that you can run from vc-dir to see what needs to be merged from
upstream, but the main vc-dir command should be as quick as possible, to
show you the current state of the tree, i.e. which files are
locally modified.


        Stefan

Re: vc-status vs pcl-cvs

[Nick Roberts]

 >   > vc-dir isn't documented (but vc-directory is)...
 > 
 > Patches are welcome.

My point was not that vc-dir is a work in progress (Stephan has already said
that) but that vc-directory was in some ways better so should not have been
removed.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: vc-status vs pcl-cvs

[Dan Nicolaescu]

Nick Roberts <nickrob@snap.net.nz> writes:

  >  > > In that case, do you think [it was] premature to remove vc-directory which
  >  > > was better at doing some of the things vc-dir should do?
  >  > 
  >  > AFAIK, it has the same "commit in foreground" and "no way to update the
  >  > whole direcrory" problem.  VC-dir is missing some features, but which
  >  > ones (other than the obvious ones from dired which probably won't be
  >  > added to vc-dir anyway) were present in vc-dired?
  > 
  >  vc-dir isn't documented (but vc-directory is)...

Actually, ESR updated the documentation a few weeks ago.

Re: vc-status vs pcl-cvs

[Nick Roberts]

 >   >  vc-dir isn't documented (but vc-directory is)...
 > 
 > Actually, ESR updated the documentation a few weeks ago.

I missed that because it says:

                                         You can use the
command `C-x v d' (`vc-directory')...

Presumably that should be `C-x v d' (`vc-dir').

What does vc-dir do better than vc-directory?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: vc-status vs pcl-cvs

[Stefan Monnier]

>> >  vc-dir isn't documented (but vc-directory is)...
>> Actually, ESR updated the documentation a few weeks ago.
> I missed that because it says:
>                                          You can use the
> command `C-x v d' (`vc-directory')...

> Presumably that should be `C-x v d' (`vc-dir').
> What does vc-dir do better than vc-directory?

Mostly: speed.


        Stefan

Re: vc-status vs pcl-cvs

[Sam Steingold]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Monnier wrote:
|> I am trying to switch from pcl-cvs to vc-status to use the same
|> interface for cvs and hg.
|
|> I have the following problems though:
|
|> 1. commit is in foreground, not background.
|
| Yes, patches welcome.
|
|> 2. there is no way to update the whole directory (O in pcl-cvs runs
|> cvs-mode-update which runs "cvs up" on the selection or the whole
|> directory).
|
| Indeed, patches welcome.

Alas, both of these run counter the current design and would require a
serious rewrite of major parts.

commit entails much work afterwards, so it has to be synchronous. ISTR
that there is a way to run a function after an asynchronous process
finishes (how?), but all backends would have to be changed to support that.

update is even worse: vc-update is _file_ oriented, it will want to
call, e.g., "hg pull -u" for _each_ file in the fileset (never mind that
the command makes sense only for the whole repository).


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIRrvLPp1Qsf2qnMcRAmxFAKCeyj7icC518bf04qsRCl57mnNMogCfTsxI
SzehN442aJluoVrSfWkNYhQ=
=o+9X
-----END PGP SIGNATURE-----