From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: State of VC? Date: Tue, 22 Jan 2008 14:07:53 -0800 Message-ID: <200801222207.m0MM7rlR014153@sallyv1.ics.uci.edu> References: <20080122164306.3B33C83045C@snark.thyrsus.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1201039773 4882 80.91.229.12 (22 Jan 2008 22:09:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Jan 2008 22:09:33 +0000 (UTC) Cc: "Eric S. Raymond" , emacs-devel@gnu.org To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 22 23:09:51 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 1JHRJQ-0007f4-9y for ged-emacs-devel@m.gmane.org; Tue, 22 Jan 2008 23:09:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JHRJ0-0001SR-DJ for ged-emacs-devel@m.gmane.org; Tue, 22 Jan 2008 17:09:18 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JHRIv-0001SM-8j for emacs-devel@gnu.org; Tue, 22 Jan 2008 17:09:13 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JHRIu-0001S7-FX for emacs-devel@gnu.org; Tue, 22 Jan 2008 17:09:12 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JHRIu-0001S4-9c for emacs-devel@gnu.org; Tue, 22 Jan 2008 17:09:12 -0500 Original-Received: from sallyv1.ics.uci.edu ([128.195.1.109]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1JHRIt-0004NE-Mb for emacs-devel@gnu.org; Tue, 22 Jan 2008 17:09:12 -0500 X-ICS-MailScanner-Watermark: 1201644475.49151@igDyS5dD7IN8EPDNixZSSA Original-Received: from mothra.ics.uci.edu (mothra.ics.uci.edu [128.195.6.93]) by sallyv1.ics.uci.edu (8.13.7+Sun/8.13.7) with ESMTP id m0MM7rlR014153; Tue, 22 Jan 2008 14:07:53 -0800 (PST) In-Reply-To: (Tom Tromey's message of "Tue, 22 Jan 2008 10:08:50 -0700") Original-Lines: 131 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.363, required 5, autolearn=disabled, ALL_TRUSTED -1.44, TW_SV 0.08) X-ICS-MailScanner-From: dann@mothra.ics.uci.edu X-detected-kernel: by monty-python.gnu.org: Solaris 10 (beta) 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:87317 Archived-At: Tom Tromey writes: > >>>>> "Eric" == Eric S Raymond 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