Re: vc-*-root finctions

[Mike Mattie <codermattie@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4190 bytes --]

On Thu, 21 Feb 2008 16:33:01 +0100
Thien-Thi Nguyen <ttn@gnuvola.org> wrote:

> () Dan Nicolaescu <dann@ics.uci.edu>
> () Wed, 20 Feb 2008 10:50:41 -0800
> 
[snip]
 
>    Why bother making the backend synchronous?
> 
> To support asynchronous behavior well, we wish to keep the user
> informed, i.e, updating some visible status at the asynchronous
> boundaries (twice). If the backend is very fast (completes below some
> threshold, say 0.5 sec), this double update appears as a flickering,
> and is not only uninformative, it may be downright bewildering.
> Thus, a friendly backend may choose to operate synchronously if it is
> confident that it can do its job under some other reasonable
> threshold for user patience (say 3-5 seconds).  This is the backend's
> business; vc.el should not presume to know.
> 
> You can see this consideration in play in vc-git-dir-status, which
> eschews asynchronous operation completely, so confident it is.  On
> the other hand, in vc-svn-dir-status, i have placed a TODO comment
> where someone who knows subversion better can add code to dynamically
> determine how to DTRT there.

I know a bit of svn. I'll drop a couple of notes since it might take me
a while to personally work my way to the svn backend.

async:

* checkin/checkout
* command has a URL in it
* log command

sync:

* a working copy command that affects the HEAD revision of the checkout, since svn has cached
  a copy of the checkout on disk.

  These commands must *not* have a -r revision argument or svn will attempt to contact the repository
  even if there is a local cache of that revision.

  This is actually a problem with vc on my Emacs 23.0.60.2. none of the "offline" commands work, I think
  because internally vc supplies revision arguments to all commands ?

  This includes diff and revert which often puts me back in eshell.

Notes:

If you are working with fork/exec IPC to the svn client you have to be very careful not to trust the exit status
of the client.

I encountered this issue when I wrote a perl wrapper around svn to normalize the command set. I would generate a commit
command, the client would terminate with exit status == 0, and the command failed with no effect visible in the working
copy or repository.

When doing commit commands the reliable way to see if a command worked is to make sure that svn returns a revision number
on stdout. If there is no output at all the command failed.

Also might need to be an artificial delay between rapid fire commits. My perl script generated about 13 commits in a few seconds
resulting in corruption of the working copy, locked files, and a half-committed repository, despite all commands supposedly
terminating normally.

I am not sure how much of a delay is required.

I reported a bug to svn with the logs of the event, but I did not receive a response.

Speaking of locked files, the svn status needs to be scanned after commands that update the working copy or repository
meta-data, looking for internal transactions that require a svn cleanup command to clear. best place to run a cleanup
scan is before such a command.

It will be a while before my revision control project winds it's way into vc, currently I am focused on ediff and quilt.
When it does I will transfer my knowledge from my perl script which knows alot about svn, to vc, which obsoletes my
perl script.

When I stopped working on that perl script I was seriously thinking about using the library API with bindings
instead of a fork/exec IPC. The client problems would likely disappear when accessing the internal API. Emacs
probably wouldn't be able to do this the right way without the ability to load the host system's shared
objects though.

Cheers,
Mike Mattie

P.S:

VC misfeature?

The vc command update, or C-x v + always attempts to update the working copy from the repository. When the CLI
is used in conjunction with vc, you often want to update the buffer: reload the file from disk, and update the
vc modeline information, without performing a checkout. I don't know of a way to update without checkout -
it would be nice.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]