Re: State of VC?

[Tom Tromey <tromey@redhat.com>]

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