From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Dan Nicolaescu <dann@ics.uci.edu>
Cc: emacs-devel@gnu.org
Subject: Re: conflict state
Date: Wed, 09 Apr 2008 16:35:43 -0400 [thread overview]
Message-ID: <jwvfxtuhjek.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <200804081503.m38F3C3A019899@sallyv1.ics.uci.edu> (Dan Nicolaescu's message of "Tue, 08 Apr 2008 08:03:12 -0700")
>> > 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.
> 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.
I'd rather just use the same for edited and conflict if we can't come up
with a good one.
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, ...).
> +;; - 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.
> @@ -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.
We should probably arrange to call mark-resolved from vc-after-save
(after checking that all the conflicts were indeed resolved).
Stefan
next prev parent reply other threads:[~2008-04-09 20:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-06 5:54 VC state Stefan Monnier
2008-04-06 17:40 ` Dan Nicolaescu
2008-04-07 15:16 ` Stefan Monnier
2008-04-08 15:03 ` conflict state (was Re: VC state) Dan Nicolaescu
2008-04-09 20:35 ` Stefan Monnier [this message]
2008-04-09 21:39 ` conflict state Dan Nicolaescu
2008-04-10 0:44 ` Stefan Monnier
2008-04-08 20:45 ` VC state Dan Nicolaescu
2008-04-09 2:44 ` Stefan Monnier
2008-04-09 3:07 ` Dan Nicolaescu
2008-04-09 3:52 ` Nick Roberts
2008-04-09 22:54 ` Dan Nicolaescu
2008-04-10 5:53 ` VC development [was Re: VC state] Nick Roberts
2008-04-10 8:33 ` VC state Nick Roberts
2008-04-10 14:13 ` Dan Nicolaescu
2008-04-11 12:01 ` Nick Roberts
2008-04-10 19:17 ` Stefan Monnier
2008-04-09 14:02 ` Stefan Monnier
2008-04-10 17:28 ` Dan Nicolaescu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvfxtuhjek.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=dann@ics.uci.edu \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.