State of VC?

State of VC?

[Eric S. Raymond]

I was on the road, with only spotty access to email, all last week.
During this time there was, apparently, a lot of VC-related activity 
including discussion of a new interface that has been partially 
implemented, and several patches flying back and forth. 

I have time to work on VC and consider myself responsible for it
(especially since the new-VC rewrite).  But I am unclear on what needs
to be done with VC at this point.

Would those of you who have been hacking please summarize the design
and coding issues as you see them?  From that I will try to put together
some sort of roadmap and get a start on executing it.  
--
					>>esr>>

Re: State of VC?

[Tom Tromey]

>>>>> "Eric" == Eric S Raymond <esr@snark.thyrsus.com> writes:

Eric> I have time to work on VC and consider myself responsible for it
Eric> (especially since the new-VC rewrite).  But I am unclear on what needs
Eric> to be done with VC at this point.

There are a few bug reports, some with patches, that were never looked
at.  Reviewing those would be a good start.

Eric> Would those of you who have been hacking please summarize the
Eric> design and coding issues as you see them?  From that I will try
Eric> to put together some sort of roadmap and get a start on
Eric> executing it.

This is my list for vc-status.  It is roughly in order from core
pieces to UI.

* Make a new 'update' back end function to update the tree.

* Make dir-status back end function update the vc-status buffer
  asynchronously.  This means using a process filter.

* Don't clear vc-status buffer when updating.  This means figuring out
  how to insert new items into the ewoc at the right point.

* Figure out what to do about 'conflict' -- seems like it should be a
  state, but none of VC seems prepared for that.  There was some
  discussion about this.

* Add more bindings.  At least 'commit' and 'update' are needed.
  In general, copy stuff from pcl-cvs or psvn.
  We also need a menu and maybe a toolbar.

* Implement dir-status and update functions for all back ends.

* A few rough edges... allow multiple vc-status buffers.  Decide
  general approach to running the sub-process (what buffer to use,
  etc; there was some traffic about this).  Decide how to allow
  interrupting the process.  Update the vc-status buffer when a
  modification is made to a buffer visiting one of the listed files.

* Whatever else that pcl-cvs does that is cool that vc-status should
  have.

FWIW I am hardly working on this.  I send a patch as the mood strikes.
So, don't worry too much about duplicating effort :).  Dan, I think,
is leading it.

I probably forgot something.

Tom

Re: State of VC?

[Tom Tromey]

Tom> There are a few bug reports, some with patches, that were never looked
Tom> at.  Reviewing those would be a good start.

Dan> Pointers? 
Dan> I only remember one bug:
Dan> http://permalink.gmane.org/gmane.emacs.devel/87064

http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg00549.html
  (this patch is probably bogus)

http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg00267.html

http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg00410.html
  (a patch, not really a bug)

I also reported one about use of shrink-window-if-larger-than-buffer
and VC, but I don't see it right now.

Dan> By this time I think that we can declare the vc-status experiment a
Dan> success. It is in decent shape and the code is still very simple and
Dan> understandable.  Do you agree?

I think it has potential, but it is not ready.

Dan> ;; - vc-register should register multiple files at a time. The
Dan> ;;  `register' backend function already supports that.

This item is listed twice.

Tom> * Make dir-status back end function update the vc-status buffer
Tom> asynchronously.  This means using a process filter.

Dan> I am not yet convinced that we should do this. The discussion on this
Dan> was started by your observation that PCL-CVS and psvn "pause" when
Dan> updating the display. It would be good to actually investigate and see
Dan> what the cause of the "pause" is, and make sure that it can be fixed by
Dan> going asynchronous. 

According to the psvn maintainer it is due to sorting the entries
after svn exits.

Anyway the experiment is pretty easy.  I will try to remember to do it.

Tom> * Don't clear vc-status buffer when updating.  This means figuring out
Tom> how to insert new items into the ewoc at the right point.

Dan> We don't need to do this right away an easy stopgap: we can keep a list
Dan> of selected items and select them at the time they are inserted.

This is not the same if a marked file changes from modified to unmodified.
In this case it will disappear from the listing.

IMO it is nicer UI for the entries to persist a bit.

Tom

Re: State of VC?

[Dan Nicolaescu]

Tom Tromey <tromey@redhat.com> writes:

  > >>>>> "Eric" == Eric S Raymond <esr@snark.thyrsus.com> writes:
  > 
  > Eric> I have time to work on VC and consider myself responsible for it
  > Eric> (especially since the new-VC rewrite).  But I am unclear on what needs
  > Eric> to be done with VC at this point.
  > 
  > There are a few bug reports, some with patches, that were never looked
  > at.  Reviewing those would be a good start.

Pointers? 
I only remember one bug:
http://permalink.gmane.org/gmane.emacs.devel/87064

  > Eric> Would those of you who have been hacking please summarize the
  > Eric> design and coding issues as you see them?  From that I will try
  > Eric> to put together some sort of roadmap and get a start on
  > Eric> executing it.

Most code discussion has been about vc-status.

By this time I think that we can declare the vc-status experiment a
success. It is in decent shape and the code is still very simple and
understandable.  Do you agree?

I added a TODO list to vc.el, and I have some additions to that list in
my uncommitted tree.  IMO this list can be used as a start for a
roadmap. Here's the list:

;; - Make vc-checkin avoid reverting the buffer if has not changed
;;   after the checkin.  Comparing (md5 BUFFER) to (md5 FILE) should
;;   be enough.
;;
;; - vc-update/vc-merge should deal with VC systems that don't
;;   update/merge on a file basis, but on a whole repository basis.
;;
;; - vc-register should register multiple files at a time. The
;;  `register' backend function already supports that.
;;
;; - the backend sometimes knows when a file it opens has been marked
;;   by the VCS as having a "conflict". Find a way to pass this info -
;;   to VC so that it can turn on smerge-mode when opening such a
;;   file.
;;
;; - the *VC-log* buffer needs font-locking.
;;
;; - make it easier to write logs, maybe C-x 4 a should add to the log
;;   buffer if there's one instead of the ChangeLog.
;;
;; - make vc-state for all backends return 'unregistered instead of
;;   nil for unregistered files, then update vc-next-action.
;;
;; - add a generic mechanism for remembering the current branch names,
;;   display the branch name in the mode-line. Replace
;;   vc-cvs-sticky-tag with that.
;; 
;; - vc-register should register a fileset at a time. The backends
;;   already support this, only the front-end needs to be change to
;;   handle multiple files at a time.
;;
;; - deal with push/pull operations.
;;
;; - decide if vc-status should replace vc-dired.
;;
;; - vc-status needs a menu, mouse bindings and some color bling.
;;
;; - "snapshots" should be renamed to "branches", and thoroughly
;;   reworked.
;;

Now, onto Tom's list:

  > This is my list for vc-status.  It is roughly in order from core
  > pieces to UI.
  > 
  > * Make a new 'update' back end function to update the tree.
  > 
  > * Make dir-status back end function update the vc-status buffer
  >   asynchronously.  This means using a process filter.

I am not yet convinced that we should do this. The discussion on this
was started by your observation that PCL-CVS and psvn "pause" when
updating the display. It would be good to actually investigate and see
what the cause of the "pause" is, and make sure that it can be fixed by
going asynchronous. 

Anyway, updating asynchronously is not a big change from the vc.el point
of view. Just a few lines need to change. The backends would have to
change more stuff to use process filters. But that should not be too
hard either once there a working model.

  > * Don't clear vc-status buffer when updating.  This means figuring out
  >   how to insert new items into the ewoc at the right point.

We don't need to do this right away an easy stopgap: we can keep a list
of selected items and select them at the time they are inserted.

  > * Figure out what to do about 'conflict' -- seems like it should be a
  >   state, but none of VC seems prepared for that.  There was some
  >   discussion about this.
  > 
  > * Add more bindings.  At least 'commit' and 'update' are needed.
  >   In general, copy stuff from pcl-cvs or psvn.
  >   We also need a menu and maybe a toolbar.
  >
  > * Implement dir-status and update functions for all back ends.
  >
  > * A few rough edges... allow multiple vc-status buffers.  Decide
  >   general approach to running the sub-process (what buffer to use,
  >   etc; there was some traffic about this).  Decide how to allow
  >   interrupting the process.  Update the vc-status buffer when a
  >   modification is made to a buffer visiting one of the listed files.

Agreed.

  > * Whatever else that pcl-cvs does that is cool that vc-status should
  >   have.

One such cool thing is: when a files is modified and its directory is
shown in a vc-status buffer, add it there. 

  > FWIW I am hardly working on this.  I send a patch as the mood
  > strikes.  So, don't worry too much about duplicating effort :).
  > Dan, I think, is leading it.

Hehe, hardly. I don't really have time to lead this properly, so the job
is up for grabs :-)


      --dan

Re: State of VC?

[Glenn Morris]

Dan Nicolaescu wrote:

> Pointers? 
> I only remember one bug:
> http://permalink.gmane.org/gmane.emacs.devel/87064

Links to VC-related issues that are unaddressed AFAIK. Some of them
may well be dealt with - you will know better than I.


strange window behavior from vc-diff
http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg01276.html

vc-dired refresh
http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg01268.html

Patch: vc-dired-hook -vs- vc-call
http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg00549.html

Further VC tuning is blocked
http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg00410.html

strange byte compiler behavior
http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01356.html

vc.el complaint about reference to free variable `file'
http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg00872.html

wrong behaviour of vc-workfile-unchanged-p
http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg00867.html

[chet.wood@sun.com: vc-sccs-workfile-version returns wrong version number]
http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg01572.html

[bojohan+mail@dd.chalmers.se: Re: vc-annotate bugs]
http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg01390.html

Re: State of VC?

[Stefan Monnier]

> This is not the same if a marked file changes from modified to unmodified.
> In this case it will disappear from the listing.

That's pretty much how PCL-CVS used to work, and indeed it sucked.
Now PCL-CVS tries to never remove entries unless the user asks for it
explicitly (typically with the `x' key which says "remove up-to-date
entries").
Actually, I find that the *cvs* buffer should also always list files
that are open in an Emacs buffer.  E.g. I use a find-file-hook to
automatically add files I visit to the *cvs* buffer(s).


        Stefan

Re: State of VC?

[Johan Bockgård]

Glenn Morris <rgm@gnu.org> writes:

> [bojohan+mail@dd.chalmers.se: Re: vc-annotate bugs]
> http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg01390.html

This one has been fixed.

-- 
Johan Bockgård

Re: State of VC?

[Dan Nicolaescu]

Tom Tromey <tromey@redhat.com> writes:

  > Tom> There are a few bug reports, some with patches, that were never looked
  > Tom> at.  Reviewing those would be a good start.
  > 
  > Dan> Pointers? 
  > Dan> I only remember one bug:
  > Dan> http://permalink.gmane.org/gmane.emacs.devel/87064
  > 
  > http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg00549.html
  >   (this patch is probably bogus)

Does this still happen? This might have been due to bugs due to the
introduction of the ignored and unregistered states.

  > http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg00267.html

This should have been fixed by a different patch.

  > http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg00410.html
  >   (a patch, not really a bug)

Don't know about this one. If you think is correct and you tested it, I
can check it in.  Although I hope you get commit access soon.

  > I also reported one about use of shrink-window-if-larger-than-buffer
  > and VC, but I don't see it right now.

Glenn posted a link to that one.

  > Dan> By this time I think that we can declare the vc-status experiment a
  > Dan> success. It is in decent shape and the code is still very simple and
  > Dan> understandable.  Do you agree?
  > 
  > I think it has potential, but it is not ready.

Sure it's not.  The point here is just to move it from the
"experimental, can be deleted anytime" state to "work in progress, this
is the future" so that more people can work on this.

  > Tom> * Make dir-status back end function update the vc-status buffer
  > Tom> asynchronously.  This means using a process filter.
  > 
  > Dan> I am not yet convinced that we should do this. The discussion on this
  > Dan> was started by your observation that PCL-CVS and psvn "pause" when
  > Dan> updating the display. It would be good to actually investigate and see
  > Dan> what the cause of the "pause" is, and make sure that it can be fixed by
  > Dan> going asynchronous. 
  > 
  > According to the psvn maintainer it is due to sorting the entries
  > after svn exits.
  > 
  > Anyway the experiment is pretty easy.  I will try to remember to do it.

OK, thanks.

  > Tom> * Don't clear vc-status buffer when updating.  This means figuring out
  > Tom> how to insert new items into the ewoc at the right point.
  > 
  > Dan> We don't need to do this right away an easy stopgap: we can keep a list
  > Dan> of selected items and select them at the time they are inserted.
  > 
  > This is not the same if a marked file changes from modified to unmodified.
  > In this case it will disappear from the listing.
  > 
  > IMO it is nicer UI for the entries to persist a bit.

OK. Would this need a change in the interface to the backend?

Re: State of VC?

[Dan Nicolaescu]

Glenn Morris <rgm@gnu.org> writes:

  > Dan Nicolaescu wrote:
  > 
  > > Pointers? 
  > > I only remember one bug:
  > > http://permalink.gmane.org/gmane.emacs.devel/87064
  > 
  > Links to VC-related issues that are unaddressed AFAIK. Some of them
  > may well be dealt with - you will know better than I.
  > 
  > 
  > strange window behavior from vc-diff
  > http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg01276.html

The problem here is indeed in vc-diff-sentinel. It calls 
(shrink-window-if-larger-than-buffer)
which does this:
  (when (null window)
    (setq window (selected-window)))

So it will look at (selected-window), so it will shrink the wrong
window... 
Not sure what the best solution is here.

  > vc-dired refresh
  > http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg01268.html

This is for vc-dired. Needs to be looked checked if it still happens
when vc-dired is replaced with vc-status.

  > Patch: vc-dired-hook -vs- vc-call
  > http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg00549.html
  >
  > Further VC tuning is blocked
  > http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg00410.html

Already replied about these in another message.

  > strange byte compiler behavior
  > http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01356.html
  > 
  > vc.el complaint about reference to free variable `file'
  > http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg00872.html

Still need fixing.

  > wrong behaviour of vc-workfile-unchanged-p
  > http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg00867.html

The analysis in the bug report seems correct.
Opinions on this patch?
(this code has been around for a long time...)

--- vc-hooks.el.~1.220.~2008-01-13 10:45:01.000000000 -0800
+++ vc-hooks.el2008-01-23 23:01:02.000000000 -0800
@@ -558,10 +558,11 @@
     (if (and checkout-time
              ;; Tramp and Ange-FTP return this when they don't know the time.
              (not (equal lastmod '(0 0))))
-        (equal checkout-time lastmod)
-      (let ((unchanged (vc-call workfile-unchanged-p file)))
-        (vc-file-setprop file 'vc-checkout-time (if unchanged lastmod 0))
-        unchanged))))
+        (if (equal checkout-time lastmod)
+    t
+  (let ((unchanged (vc-call workfile-unchanged-p file)))
+    (vc-file-setprop file 'vc-checkout-time (if unchanged lastmod 0))
+    unchanged)))))
 
 (defun vc-default-workfile-unchanged-p (backend file)
   "Check if FILE is unchanged by diffing against the master version.


  > [chet.wood@sun.com: vc-sccs-workfile-version returns wrong version number]
  > http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg01572.html

No idea.

Re: State of VC?

[Thien-Thi Nguyen]

() Dan Nicolaescu <dann@ics.uci.edu>
() Wed, 23 Jan 2008 23:07:19 -0800

   The problem here is indeed in vc-diff-sentinel. It calls 
   (shrink-window-if-larger-than-buffer)
   which does this:
     (when (null window)
       (setq window (selected-window)))

   So it will look at (selected-window), so it will shrink the wrong
   window... 
   Not sure what the best solution is here.

i just installed a fix.

btw, in the cvs log, i used the format:

  ONE-LINE-DESCRIPTION.
  
  (FUNC): CHANGE.
  (OTHER-FUNC): CHANGE.
  
as opposed to the format w/o `ONE-LINE-DESCRIPTION.\n\n'
(which is what went into ChangeLog).  any objections?

thi

Re: State of VC?

[Thien-Thi Nguyen]

() Glenn Morris <rgm@gnu.org>
() Tue, 22 Jan 2008 17:26:26 -0500

   strange byte compiler behavior
   http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01356.html

IIRC someone wanted to investigate the byte compiler's diagnostics, thus
delaying resolution of the next bug.  However, that doesn't seem as
important to me as fixing the bug, so...

   vc.el complaint about reference to free variable `file'
   http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg00872.html

I just installed a fix.

thi

Re: State of VC?

[Stefan Monnier]

> i just installed a fix.

Plese fix your fix so that it doesn't use just (get-buffer-window buf)
but (get-buffer-window buf t) like in the fix I installed minutes before
on the 22 branch.

The third argument to get-buffer-window really should not be optional,
to force people to think a bit more about the multi-frame case, which is
all too often ignored.


        Stefan

Re: State of VC?

[Thien-Thi Nguyen]

() Stefan Monnier <monnier@iro.umontreal.ca>
() Thu, 24 Jan 2008 09:57:12 -0500

   (get-buffer-window buf t)

thanks for catching this.  installed.

   The third argument to get-buffer-window really should not be
   optional, to force people to think a bit more about the
   multi-frame case, which is all too often ignored.

good point.  i know i often fail to think of multi-frame case.

thi

Re: State of VC?

[Tom Tromey]

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

>> http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg00549.html
>> (this patch is probably bogus)

Dan> Does this still happen? This might have been due to bugs due to the
Dan> introduction of the ignored and unregistered states.

I will try to look soon.

>> http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg00410.html
>> (a patch, not really a bug)

Dan> Don't know about this one. If you think is correct and you tested
Dan> it, I can check it in.

This one I think is ok.  I'm not in a super rush to get it in though;
this list was really just stuff for ESR to mull over.

[vc-status]
>> I think it has potential, but it is not ready.

Dan> Sure it's not.  The point here is just to move it from the
Dan> "experimental, can be deleted anytime" state to "work in progress, this
Dan> is the future" so that more people can work on this.

We are in complete agreement :)

>> This is not the same if a marked file changes from modified to unmodified.
>> In this case it will disappear from the listing.

Dan> OK. Would this need a change in the interface to the backend?

I don't think so.  Maybe it would be nice to have a function that is
called to indicate that the update is complete... that's come up a
couple times.

Tom

Re: State of VC?

[Richard Stallman]

    The third argument to get-buffer-window really should not be optional,
    to force people to think a bit more about the multi-frame case, which is
    all too often ignored.

That is a good point, but I think such a change would break lots of
old code, and thus is a bad idea.

Re: State of VC?

[Stefan Monnier]

>     The third argument to get-buffer-window really should not be optional,
>     to force people to think a bit more about the multi-frame case, which is
>     all too often ignored.

> That is a good point, but I think such a change would break lots of
> old code, and thus is a bad idea.

Yes, I didn't mean to change it, I meant it as "the way things should be
in an ideal world".


        Stefan

Re: State of VC?

[Alexandru Harsanyi]

On 24 Jan 2008, at 4:07 PM, Dan Nicolaescu wrote:
>
>> wrong behaviour of vc-workfile-unchanged-p
>> http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg00867.html
>
> The analysis in the bug report seems correct.
> Opinions on this patch?
> (this code has been around for a long time...)
>
> --- vc-hooks.el.~1.220.~2008-01-13 10:45:01.000000000 -0800
> +++ vc-hooks.el2008-01-23 23:01:02.000000000 -0800
> @@ -558,10 +558,11 @@
>      (if (and checkout-time
>               ;; Tramp and Ange-FTP return this when they don't  
> know the time.
>               (not (equal lastmod '(0 0))))
> -        (equal checkout-time lastmod)
> -      (let ((unchanged (vc-call workfile-unchanged-p file)))
> -        (vc-file-setprop file 'vc-checkout-time (if unchanged  
> lastmod 0))
> -        unchanged))))
> +        (if (equal checkout-time lastmod)
> +    t
> +  (let ((unchanged (vc-call workfile-unchanged-p file)))
> +    (vc-file-setprop file 'vc-checkout-time (if unchanged lastmod 0))
> +    unchanged)))))
>
>  (defun vc-default-workfile-unchanged-p (backend file)
>    "Check if FILE is unchanged by diffing against the master version.
>

with the above changes, vc-workfile-unchanged-p will return nil when  
the test for the first if is false (and checkout-time ...).  This vc  
will consider the file changed each time the checkout-time is not  
known.  How about:


Index: vc-hooks.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/vc-hooks.el,v
retrieving revision 1.220
diff -u -p -r1.220 vc-hooks.el
--- vc-hooks.el	8 Jan 2008 20:44:35 -0000	1.220
+++ vc-hooks.el	26 Jan 2008 07:45:06 -0000
@@ -557,11 +557,12 @@ and does not employ any heuristic at all
          (lastmod (nth 5 (file-attributes file))))
      (if (and checkout-time
               ;; Tramp and Ange-FTP return this when they don't know  
the time.
-             (not (equal lastmod '(0 0))))
-        (equal checkout-time lastmod)
-      (let ((unchanged (vc-call workfile-unchanged-p file)))
-        (vc-file-setprop file 'vc-checkout-time (if unchanged  
lastmod 0))
-        unchanged))))
+             (not (equal lastmod '(0 0)))
+             (equal checkout-time lastmod))
+        t
+        (let ((unchanged (vc-call workfile-unchanged-p file)))
+          (vc-file-setprop file 'vc-checkout-time (if unchanged  
lastmod 0))
+          unchanged))))

  (defun vc-default-workfile-unchanged-p (backend file)
    "Check if FILE is unchanged by diffing against the master version.


Cheers,
Alex.

Re: State of VC?

[Dan Nicolaescu]

Tom Tromey <tromey@redhat.com> writes:

  > >>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > >> This is not the same if a marked file changes from modified to unmodified.
  > >> In this case it will disappear from the listing.
  > 
  > Dan> OK. Would this need a change in the interface to the backend?
  > 
  > I don't think so.  Maybe it would be nice to have a function that is
  > called to indicate that the update is complete... that's come up a
  > couple times.

That seems to be necessary only when doing partial updates.  Now the
update is complete when vc-update-vc-status-buffer gets called.

But maybe first we should wait for ESR to post his plan/roadmap before
doing any further changes. Hopefully this will happen soon ... 

Re: State of VC?

[Eric S. Raymond]

Dan Nicolaescu <dann@ics.uci.edu>:
> But maybe first we should wait for ESR to post his plan/roadmap before
> doing any further changes. Hopefully this will happen soon ... 

Sorry about the delay; we're prepping for a release on another project
of mine at the moment.  I should be able to get to this Tuesday or Wednesday.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: State of VC?

[Dan Nicolaescu]

"Eric S. Raymond" <esr@thyrsus.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu>:
  > > But maybe first we should wait for ESR to post his plan/roadmap before
  > > doing any further changes. Hopefully this will happen soon ... 
  > 
  > Sorry about the delay; we're prepping for a release on another project
  > of mine at the moment.  I should be able to get to this Tuesday or Wednesday.

Any news about this?

IMO the most pressing need right now is to move vc-status from it's
state of limbo.

Given how simple the vc-status code is, how easy it is to extend, and
how long it took for fundamental problems in vc-dired to be fixed, it's
quite easy to conclude that vc-status is the best way to go forward.

Re: State of VC?

[Thien-Thi Nguyen]

Is anyone writing vc-git-dir-status?

thi

Re: State of VC?

[Dan Nicolaescu]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

  > Is anyone writing vc-git-dir-status?

AFAIK no.

Re: State of VC?

[Eric S. Raymond]

Dan Nicolaescu <dann@ics.uci.edu>:
> "Eric S. Raymond" <esr@thyrsus.com> writes:
> 
>   > Dan Nicolaescu <dann@ics.uci.edu>:
>   > > But maybe first we should wait for ESR to post his plan/roadmap before
>   > > doing any further changes. Hopefully this will happen soon ... 
>   > 
>   > Sorry about the delay; we're prepping for a release on another project
>   > of mine at the moment.  I should be able to get to this Tuesday or Wednesday.
> 
> Any news about this?
> 
> IMO the most pressing need right now is to move vc-status from it's
> state of limbo.
> 
> Given how simple the vc-status code is, how easy it is to extend, and
> how long it took for fundamental problems in vc-dired to be fixed, it's
> quite easy to conclude that vc-status is the best way to go forward.

Sorry, I've been heads-down on another project.  Actually it's Battle For 
Wesnoth, the one I've held up as a tool-use model here.  We're heading
towards a major stable 1.4 release and, as I'm one of the core devs, this 
involves a huge amount of work.

I'll get back to working on VC probably around the first week of
March, possibly earlier.  In the meantime, anybody who wants to take the
initiative on moving VC to use vc-status sooner has my approval and 
encouragement to do it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: State of VC?

[Thien-Thi Nguyen]

() Dan Nicolaescu <dann@ics.uci.edu>
() Sun, 17 Feb 2008 10:56:24 -0800

   AFAIK no.

I have just added vc-dir-status for Git.  Sigh, moments after
the C-c C-c, i see new func vc-git--ls-files-state, which
probably could have been useful.  However, before doing any
more munging, it would be nice for us to figure out what is
vc-dir-status philosophy and design, and write that down in a
vc.el comment so that backend support can derive guidance and
check for conformance.  Labeling everything EXPERIMENTAL is
lame; one such warning in vc.el should suffice.

Personally, i don't think vc-directory for Git is that bad
(w/ some tweaking)[0].  I *like* the "v" prefix, non-flat
(visible) directory hierarchy, and support for RCS and CVS.
I get the feeling that vc-dir-status is simply ewoc wanking.
Perhaps a nice comment in vc.el would dispell that, hint hint.

thi


__________________________________________________________
[0] mentioned before, but there have been updates since:
    http://www.gnuvola.org/wip/  (see vc-git-hacking)

Re: State of VC?

[Miles Bader]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:
> Personally, i don't think vc-directory for Git is that bad
> (w/ some tweaking)[0].  I *like* the "v" prefix, non-flat
> (visible) directory hierarchy, and support for RCS and CVS.

Is there a way to force vc-directory to not show "(ignored)" entries?
Actually, it seems kind of stupid that it shows them by default (if
they're marked "ignore", why are you showing them to me?).

-Miles

-- 
Consult, v.i. To seek another's disapproval of a course already decided on.

Re: State of VC?

[Thien-Thi Nguyen]

() Miles Bader <miles.bader@necel.com>
() Mon, 18 Feb 2008 17:36:37 +0900

   Is there a way to force vc-directory to not show "(ignored)"
   entries?

I don't see "(ignored)" entries, even w/ fresh-built "emacs -Q".

thi

Re: State of VC?

[Miles Bader]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:
>    Is there a way to force vc-directory to not show "(ignored)"
>    entries?
>
> I don't see "(ignored)" entries, even w/ fresh-built "emacs -Q".

Do you have any junk files around in that directory, which match your
git ignore specs?

If I just do M-x vc-directory RET in a git directory, I see stuff like:

  -rw-rw---- (ignored)  2007-07-31 15:16 +foo
  -rw-rw---- (ignored)  2008-01-10 15:07 ,1
  -rw-rw---- (ignored)  2008-01-10 15:19 ,2
  -rw-rw---- (ignored)  2008-01-10 15:32 ,3
  ... etc ...

[Some of the ignored stuff should be matched by my "user" gitignore file
(git config core.excludesfile), and some of it should be matched by the
.gitignore file in that directory.]

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: State of VC?

[Thien-Thi Nguyen]

() Miles Bader <miles@gnu.org>
() Mon, 18 Feb 2008 17:57:31 +0900

   Do you have any junk files around in that directory, which match
   your git ignore specs?

Yes.  For example, in .gitignore first line is "*.texi" and in the
directory there are 89 .texi files.  I don't have a "user" gitignore
file, however.  FWIW, i use git 1.5.3.5 (plus ttn mods).

thi

Re: State of VC?

[Dan Nicolaescu]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

  > () Dan Nicolaescu <dann@ics.uci.edu>
  > () Sun, 17 Feb 2008 10:56:24 -0800
  > 
  >    AFAIK no.
  > 
  > I have just added vc-dir-status for Git.  Sigh, moments after
  > the C-c C-c, i see new func vc-git--ls-files-state, which
  > probably could have been useful.  However, before doing any
  > more munging, it would be nice for us to figure out what is
  > vc-dir-status philosophy and design, and write that down in a
  > vc.el comment so that backend support can derive guidance and
  > check for conformance.  Labeling everything EXPERIMENTAL is
  > lame; one such warning in vc.el should suffice.

Sorry, but this sounds too much like a rant for missing the obvious:
the implementation for `vc-git-dir-status' should be modeled after
the thing it tries to replace: `vc-git-dir-state'.

vc-status code was added as a PROOF OF CONCEPT that it's easy to replace
vc-dired with something that is simpler, it has more features
(asynchronous), it can be easily extended and it does not take 10 years
to find fundamental bugs.  
As long as it stayed in experimental state (and that was until
yesterday) it made more sense to spend time writing proof of concept
code, and there was little point to spend time writing ISO9000 type
documents describing it.
On top of that, everything was discussed at length on the list.

  > Personally, i don't think vc-directory for Git is that bad
  > (w/ some tweaking)[0].  
You mean "vc-git-hacking"? That link does not work.
It would be more productive to add that code to vc-git, or post it here.

  >  I *like* the "v" prefix, non-flat (visible) directory hierarchy,
  > and support for RCS and CVS.

Feel free to add them. 

  > I get the feeling that vc-dir-status is simply ewoc wanking.

This bad attitude and adding this type of rants to vc-git.el:

;;; vc-dir-status support (EXPERIMENTAL)
;;; If vc-directory (which is not half bad under Git, w/ some tweaking)
;;; is to go away, vc-dir-status must at least support the same
;;; operations.  At the moment, vc-dir-status design is still fluid (a
;;; kind way to say half-baked, undocumented, and spottily-supported),
;;; so the following should be considered likewise ripe for sudden
;;; unannounced change.  YHBW, HAND.  --ttn

are totally counter-productive and seem to be designed just to aggravate
people instead of focusing on improving ANYTHING.

Re: State of VC?

[Thien-Thi Nguyen]

() Dan Nicolaescu <dann@ics.uci.edu>
() Mon, 18 Feb 2008 09:40:31 -0800

   it made more sense to spend time writing proof of concept code,
   and there was little point to spend time writing ISO9000 type
   documents describing it.  On top of that, everything was
   discussed at length on the list.

All i ask for is some comments in the source code, as a courtesy
to anyone who has not followed the discussion.  I think a brief
summary (no need for a lot of spew) of the conclusions reached,
together w/ the code, would "prove" the concept better.

     > Personally, i don't think vc-directory for Git is that bad
     > (w/ some tweaking)[0].  
   You mean "vc-git-hacking"? That link does not work.

I see this:
 $ cd /tmp
 $ git clone http://www.gnuvola.org/wip/vc-git-hacking.git
 Initialized empty Git repository in /tmp/vc-git-hacking/.git/
 got 9e2f244ec65b24f8c78d3488ca506a3b5f2892e6
 walk 9e2f244ec65b24f8c78d3488ca506a3b5f2892e6
 got 340ef0ef0a358e20ef6a468a1ac57d538aa043bf
 got b8b0d6fe86d729b7faee7eee112d1844c8a1332b
 [...53 lines deleted...]

What do you see?

   This bad attitude and adding this type of rants to vc-git.el: [...]
   are totally counter-productive and seem to be designed just to
   aggravate people instead of focusing on improving ANYTHING.

Anger is a gift, supposedly, but i can see that aggravation is
just aggravation.  To get to actual anger, you have to read the
above comment as standing in for the lack of comments in vc.el.
They are two sides of the same coin: anger from fear, fear from
ignorance, ignorance from limited attention budget; we are like
brothers now!  What is it that we fear, together?

No worries, i understand joy of implementation can occlude sense
of responsibility.  Why leave a crumb for other programmers when
the bread mashes nicely in one's maw?

I think the bad attitude to be weeded out is the one that results
in thought codified but not fully transparent.

thi

Re: State of VC?

[Dan Nicolaescu]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

  > () Dan Nicolaescu <dann@ics.uci.edu>
  > () Mon, 18 Feb 2008 09:40:31 -0800
  > 
  >    it made more sense to spend time writing proof of concept code,
  >    and there was little point to spend time writing ISO9000 type
  >    documents describing it.  On top of that, everything was
  >    discussed at length on the list.
  > 
  > All i ask for is some comments in the source code, as a courtesy
  > to anyone who has not followed the discussion.  I think a brief
  > summary (no need for a lot of spew) of the conclusions reached,
  > together w/ the code, would "prove" the concept better.

I added a description.
(Being less obnoxious about this would have been appreciated)

  >      > Personally, i don't think vc-directory for Git is that bad
  >      > (w/ some tweaking)[0].  
  >    You mean "vc-git-hacking"? That link does not work.
  > 
  > I see this:
  >  $ cd /tmp
  >  $ git clone http://www.gnuvola.org/wip/vc-git-hacking.git
  >  Initialized empty Git repository in /tmp/vc-git-hacking/.git/
  >  got 9e2f244ec65b24f8c78d3488ca506a3b5f2892e6
  >  walk 9e2f244ec65b24f8c78d3488ca506a3b5f2892e6
  >  got 340ef0ef0a358e20ef6a468a1ac57d538aa043bf
  >  got b8b0d6fe86d729b7faee7eee112d1844c8a1332b
  >  [...53 lines deleted...]
  > 
  > What do you see?

It works now, it used to give an error saying something about needing to
run update-server-info.

Re: State of VC?

[Thien-Thi Nguyen]

() Dan Nicolaescu <dann@ics.uci.edu>
() Tue, 19 Feb 2008 07:44:35 -0800

   (Being less obnoxious about this would have been appreciated)

Agreed, i find under-commented code obnoxious, as well.

thi

Re: State of VC?

[Dan Nicolaescu]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

  > () Dan Nicolaescu <dann@ics.uci.edu>
  > () Tue, 19 Feb 2008 07:44:35 -0800
  > 
  >    (Being less obnoxious about this would have been appreciated)
  > 
  > Agreed, i find under-commented code obnoxious, as well.

Now, this is a transition from obnoxious to unreasonable.  I explained
pretty clearly that the code was under development and used a demo to
ESR how things could work.  I wanted to waste no effort on stuff the
might be just thrown way.  This was done in public instead of doing it
in private email.  The amount of code is quite small and was discussed
on the list.
This silliness has gone beyond reasonable limits, so I am done
discussing it.  
If you are interested in improving the code, you are welcome to go ahead
and do it, but just talking about absolutely nothing important is just a
waste of time.

Re: State of VC?

[Thien-Thi Nguyen]

() Miles Bader <miles@gnu.org>
() Mon, 18 Feb 2008 17:57:31 +0900

   [Some of the ignored stuff should be matched by my "user"
   gitignore file (git config core.excludesfile), and some of it
   should be matched by the .gitignore file in that directory.]

I have pushed a fix for this in
http://www.gnuvola.org/wip/  (vc-status-hacking)

You might need vc-git-hacking, too, i'm not sure; they have
only been tested together, w/ the ~/.emacs frag:

  (let ((default-directory "~/build/vc-status-hacking/"))
    (load-file "loadup.el"))
  (setq vc-dired-never-show-ignored t)
  (load "~/build/vc-git-hacking/vc-git-hacking.el")

Munge hardcoded paths to taste, of course...

thi