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: conflict state Date: Wed, 09 Apr 2008 14:39:14 -0700 Message-ID: <200804092139.m39LdEhY009858@sallyv1.ics.uci.edu> References: <200804061740.m36Hemw8021394@sallyv1.ics.uci.edu> <200804081503.m38F3C3A019899@sallyv1.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1207777376 20350 80.91.229.12 (9 Apr 2008 21:42:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Apr 2008 21:42:56 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 09 23:43:29 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 1Jji4g-0003mL-Lr for ged-emacs-devel@m.gmane.org; Wed, 09 Apr 2008 23:43:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jji43-0003Sa-1V for ged-emacs-devel@m.gmane.org; Wed, 09 Apr 2008 17:42:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jji22-0001LX-Db for emacs-devel@gnu.org; Wed, 09 Apr 2008 17:40:38 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jji21-0001K6-B5 for emacs-devel@gnu.org; Wed, 09 Apr 2008 17:40:37 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jji21-0001Ju-2J for emacs-devel@gnu.org; Wed, 09 Apr 2008 17:40:37 -0400 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 1Jji20-0000Fo-Gm for emacs-devel@gnu.org; Wed, 09 Apr 2008 17:40:36 -0400 X-ICS-MailScanner-Watermark: 1208381955.04281@Ojb/VqtFv0aB8C3UAcxLHw 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 m39LdEhY009858; Wed, 9 Apr 2008 14:39:14 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Wed, 09 Apr 2008 16:35:43 -0400") Original-Lines: 119 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-0.34, required 5, autolearn=disabled, ALL_TRUSTED -1.44, FM_MULTI_ODD2 1.10) 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:94816 Archived-At: Stefan Monnier writes: > >> > This has been in Todo for a while, displaying this stuff is trivial, VC > >> > needs just to provide the information. Someone just needs to sit down > >> > and figure out how it's supposed to work in VC... > >> > >> With some backends (E.g. Svn and Bzr), it would make a lot of sense to > >> make it a new vc-state, since you need to run `(svn|bzr) resolve' to > >> switch from that state to `edited' and you can't commit before. > >> > >> In other bakends, it's less clear. Maybe you should try to simply add > >> `conflict' as a new `vc-state' and see how it works out. This will > >> require checking all uses of `vc-state' to adjust them to the new state. > > > A patch to implement the new conflict state is below. Can you please > > change the magic that runs the resolve command and turns on > > smerge-mode to use this state instead? > > I do not have time to do that right now. In that case should this code be installed? I don't have time to do this either. Maybe someone else can pick it up... > > Not sure what to do about the new `mark-resolved' backend function for > > CVS, it probably should be just a no-op, it should be easy to see once > > the smerge logic is in place. > > Yes, it should be a no-op. > > > @@ -775,10 +777,10 @@ Before doing that, check if there are an > > (eq (vc-checkout-model file) 'implicit) > > (vc-file-setprop file 'vc-state 'edited) > > (vc-mode-line file) > > - (if (featurep 'vc) > > - ;; If VC is not loaded, then there can't be > > - ;; any VC Dired buffer to synchronize. > > - (vc-dired-resynch-file file))))) > > + (when (featurep 'vc) > > + ;; If VC is not loaded, then there can't be > > + ;; any VC Dired buffer to synchronize. > > + (vc-dired-resynch-file file))))) > > > (defvar vc-menu-entry > > '(menu-item "Version Control" vc-menu-map > > Please use "diff -b" when sending patches that are intended for review > rather than for installation. > > > @@ -861,6 +863,9 @@ This function assumes that the file is r > > ((eq state 'added) > > (setq state-echo "Locally added file") > > (concat backend "@" rev)) > > + ((eq state 'conflict) > > + (setq state-echo "File contains conflicts after the last merge") > > + (concat backend "!!" rev)) > > ((eq state 'removed) > > (setq state-echo "File removed from the VC system") > > (concat backend "!" rev)) > > I'm not really happy with ! for removed and !! for conflict. No preference here, feel free to change all off them. > I'd rather just use the same for edited and conflict if we can't come up > with a good one. I'd prefer to have different things for conflict and edited so that they can be easily distinguished. > This reminds me: we have to be careful that `conflict' is for conflicts > in the file's contents. Not for conflicts about meta-info (e.g. when > a file is moved to the same location as some other file, or when a file > is renamed in two conflicting ways, ...). Are you sure that is a good idea? For systems that require a "resolve" command to be run after resolving a conflict, there needs to be some convenient way run that command. One can resolve the metadata conflict from within emacs, but then won't be able to have emacs run the resolve command. > > +;; - mark-resolved (files) > > +;; > > +;; The the VCS that conflicts have been resolved. Not all systems > > +;; need to do this. > > I don't know enough about The The to know if they're an appropriate > reference here, but I guess not. We can probably provide a > > (defalias 'vc-default-mark-resolved 'ignore) > > > +(defun vc-mark-resolved (files) > > + (with-vc-properties > > + files > > + (vc-call mark-resolved files) > > + ;; XXX: Is this TRTD? > > + `((vc-state . edited)))) > > I'd rather we just call vc-state-heuristic to get the new state. OK. > > @@ -3898,6 +3913,10 @@ to provide the `find-revision' operation > > (with-current-buffer (find-file-noselect new) > > (vc-register))) > > > +(defun vc-default-mark-resolved (backend files) > > + ;; XXX: For testing. > > + (error "Backend implements the conflict state, but it does not implement a `mark-resolved' function")) > > If we don't want to just do nothing, then let's just not provide any > default: the vc-call mechanism will then signal an error for us. OK. > We should probably arrange to call mark-resolved from vc-after-save > (after checking that all the conflicts were indeed resolved). Let's see how this turns out in real life. It seems that there might be many corner cases to consider...