From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mike Mattie Newsgroups: gmane.emacs.devel Subject: Re: vc-*-root finctions Date: Thu, 21 Feb 2008 18:42:39 -0800 Message-ID: <20080221184239.24ce4074@reforged> References: <87skzn3mq9.fsf@ambire.localdomain> <87mypvxzd2.fsf@ambire.localdomain> <200802201850.m1KIofIk000198@sallyv1.ics.uci.edu> <87tzk2xr2q.fsf@ambire.localdomain> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/AjO36CC8UT2ybmEFNigvlU9"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Trace: ger.gmane.org 1203648341 9788 80.91.229.12 (22 Feb 2008 02:45:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Feb 2008 02:45:41 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 22 03:46:06 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JSNvF-0005mt-3D for ged-emacs-devel@m.gmane.org; Fri, 22 Feb 2008 03:46:01 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JSNuk-0003FT-0t for ged-emacs-devel@m.gmane.org; Thu, 21 Feb 2008 21:45:30 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JSNug-0003EZ-JL for emacs-devel@gnu.org; Thu, 21 Feb 2008 21:45:26 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JSNuf-0003Du-Up for emacs-devel@gnu.org; Thu, 21 Feb 2008 21:45:26 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JSNuf-0003Do-Pi for emacs-devel@gnu.org; Thu, 21 Feb 2008 21:45:25 -0500 Original-Received: from wr-out-0506.google.com ([64.233.184.226]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JSNuf-0004qY-G6 for emacs-devel@gnu.org; Thu, 21 Feb 2008 21:45:25 -0500 Original-Received: by wr-out-0506.google.com with SMTP id 58so411821wri.10 for ; Thu, 21 Feb 2008 18:45:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; bh=U4Wk4ePRrAB4gQilg9Ay+QXb3b8BmO4tCcilqY2oANM=; b=Hplcl0QRpAZ8Y4T1PbVJ0P2LyJEk9GyDOxWdq69BA2AO/BP2H5RNrXJvacxN5DHwPYesFqz9eG5In/N7AAovl9SrmTSBbIt17uTP7R6hfmCNlZ9bi7jtSAdPgAVYCadwhW1rkycDVPDcfY1A1NeBiJE6Ef6yTfDgq/DAu7Lu9TQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=wYCXq/sQS9Czopbjs6CFZnlW3W4bp9oK92nN29RD28dc9VcbFA6WfXHsJdFOobnRf4YLcS5v9gSaI+FN6PUUekgV3aLNvOt6hhX0YuM2vM0VEu+93oTLi3RYEQbis1JtitQsRBRGRZICebiKxdMhf5jSMfAIeGebqSO2vNu1tOA= Original-Received: by 10.114.194.1 with SMTP id r1mr3705063waf.40.1203648323179; Thu, 21 Feb 2008 18:45:23 -0800 (PST) Original-Received: from reforged ( [71.217.206.83]) by mx.google.com with ESMTPS id n20sm1272757pof.6.2008.02.21.18.45.21 (version=SSLv3 cipher=OTHER); Thu, 21 Feb 2008 18:45:22 -0800 (PST) In-Reply-To: <87tzk2xr2q.fsf@ambire.localdomain> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.5; i686-pc-linux-gnu) X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 (Google crawlbot) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:89909 Archived-At: --Sig_/AjO36CC8UT2ybmEFNigvlU9 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 21 Feb 2008 16:33:01 +0100 Thien-Thi Nguyen wrote: > () Dan Nicolaescu > () Wed, 20 Feb 2008 10:50:41 -0800 >=20 [snip] =20 > Why bother making the backend synchronous? >=20 > 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. >=20 > 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, si= nce 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 "of= fline" 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 normaliz= e the command set. I would generate a commit command, the client would terminate with exit status =3D=3D 0, and the comm= and 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 t= o 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 pe= rl script generated about 13 commits in a few seconds resulting in corruption of the working copy, locked files, and a half-commi= tted 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 com= mand 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 v= c, currently I am focused on ediff and quilt. When it does I will transfer my knowledge from my perl script which knows a= lot about svn, to vc, which obsoletes my perl script. When I stopped working on that perl script I was seriously thinking about u= sing 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 l= oad 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 cop= y 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 w= ay to update without checkout - it would be nice. --Sig_/AjO36CC8UT2ybmEFNigvlU9 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHvjafdfRchrkBInkRAuQZAKCZhXgJ+BlF0oyggxDm/vVIBsCiVACeLW5T UpXpUiLsG6TSsIBXGILUmQo= =Dbw6 -----END PGP SIGNATURE----- --Sig_/AjO36CC8UT2ybmEFNigvlU9--