[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The VC to-do list
From: |
Stefan Monnier |
Subject: |
Re: The VC to-do list |
Date: |
Fri, 02 May 2008 22:59:59 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
> (6) ;; - figure out what to do with conflicts that are not caused by the
> ;; file contents, but by metadata or other causes.
> Example, please?
File A gets renamed to B in one branch and to C in another and you merge
the two branches. Or you locally add file FOO and then pull a change
that also adds a new file FOO, ...
> (8) ;; - vc-diff should be able to show the diff for all files in a
> ;; changeset, especially for VC systems that have per repository
> ;; version numbers. log-view should take advantage of this.
> I thought we were already doing this, at least insofar as I understand
> the specification here. What behavior is missing?
Do a log on foo.el, then for one of the changes, try to get the full
diff: that won't work, it'll only give you the foo.el part of that
changeset, not the changes made to other files.
> (10) ;; - make it easier to write logs. Maybe C-x 4 a should add to the log
> ;; buffer, if one is present, instead of adding to the ChangeLog.
> No. The real problem here is that the combination of Changelogs and
> a fileset-oriented VCS's revision history is intrinsically duplicative
> and bogus, and Changelogs should be shot through the head as soon as
> we migrate off CVS.
I don't understand this "No" since you follow it by 4 lines of text that
seem 100% in agreement with point (10). Looks like just mentioning
"ChangeLog" hits a nerve, even when the mention is going in the
direction you want.
> (14) ;; - a way to do repository wide log (instead of just per
> ;; file/fileset) is needed. Doing it per directory might be enough...
> See the notes on the dispatcher and the null-fileset problem above.
> This really has nothing to do with version-control per se, it would be
> a UI issue with the front-end design for *anything* that has (a)
> per-file, (b) per-directory, and (c) global operations. How can the
> user specify these contexts in an intuitive and consistent way?
In PCL-CVS, I used different user commands with different key-bindings
for global operations. Note that I only provided global operations for
"update" and "refresh status", so maybe it's not that relevant.
> I've already explained on-list why I don't intend to put any energy
> into this until the rest of the todo list is clear. I (a) don't think
> it's important, and (b) do fear the code bloat it seems likely to bring.
I disagree. I think it may require a lot of changes, but no code bloat
at all. It's just a matter of being careful of where we decide which
backend to use. Currently we make this decision over-and-over again at
many different places. And if one of those places makes a different
decision, we have a bug. So dealing with multiple backends is mostly
a matter of deciding which backend to use once and forall and then
properly preserving this info, which will eliminate the bugs.
Note that we've already seen such bugs for single-backend situations
because one of the files selected happens to be managed by no backend,
so we get bugs like "can't load vc-nil". This is not some hypothetical
problem. The fact that it will correctly handle multi-backend
situations is just the result of doing things right.
> (22) ;; - backends that care about vc-stay-local should try to take it into
> ;; account for vc-dir. Is this likely to be useful???
> I don't really understand stay-local or the hacks around it. I wish
> somebody else would take this one.
I think stay-local should ultimately go. It will be replaced by
a distinction between "status" and "pull --dry-run".
Another important thing: merge all the status-like backend operations.
We should remove dir-status, state, dir-state, and dir-status-files, and
replace them with just `status' which takes a fileset and a continuation
(like dir-status) and returns a buffer in which the process(es) are run
(or nil if it worked synchronously). Hopefully we can define the old
4 operations in term of this one.
Stefan