[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: vc-*-root finctions
From: |
Mike Mattie |
Subject: |
Re: vc-*-root finctions |
Date: |
Thu, 21 Feb 2008 18:42:39 -0800 |
On Thu, 21 Feb 2008 16:33:01 +0100
Thien-Thi Nguyen <address@hidden> wrote:
> () Dan Nicolaescu <address@hidden>
> () 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.
signature.asc
Description: PGP signature
- Re: vc-*-root finctions, (continued)
- Re: vc-*-root finctions, Dan Nicolaescu, 2008/02/21
- Re: vc-*-root finctions, Tom Tromey, 2008/02/21
- Re: vc-*-root finctions, Dan Nicolaescu, 2008/02/21
- Re: vc-*-root finctions, Thien-Thi Nguyen, 2008/02/22
- Re: vc-*-root finctions, Dan Nicolaescu, 2008/02/22
- Re: vc-*-root finctions, Thien-Thi Nguyen, 2008/02/22
- Re: vc-*-root finctions, Dan Nicolaescu, 2008/02/22
- Re: vc-*-root finctions,
Mike Mattie <=
- Re: vc-*-root finctions, Stefan Monnier, 2008/02/20
- Re: vc-*-root finctions, Thien-Thi Nguyen, 2008/02/21
- Re: vc-*-root finctions, Stefan Monnier, 2008/02/21
- Re: vc-*-root finctions, Thien-Thi Nguyen, 2008/02/22
- Re: vc-*-root finctions, Stefan Monnier, 2008/02/22