Re: Customizing the VC backend order

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> Hmm... that's interesting to know (I'm considering changing the way the
>> search is done, which would naturally tend to give precedence to backends
>> whose admin dir is closest, so CVS would then tend to unavoidably take
>> precedence since it's always as close as any other).

> This is very bad IMO, as if multiple systems are in use, CVS is almost
> always a legacy distribution system.

> Also, what about the RCS use-case where the ,v file is a sibling of
> the controlled file?  That's even closer, and even worse!

Yes that's what dhruva's message pointed out.

> While I see the logic behind your suggestion, I think what should be
> done is to ask the user.

The logic is sound for systems where only the topmost directory contains an
admin dir (e.g. DaRCS, Arch, Git, Mercurial, Monotone, Bazaar).  But yes,
its interaction with the other systems isn't as simple as I thought.
But asking the user is out of the question since the choice is made when
visiting a file, long before we know if the user even cares about which
backend is used.

The motivation is also to do a single "look up in parent dirs", rather than
one per backend.

> For one thing, I can see a use case where you are maintaining a variant
> version of an external library as a subdirectory of your project.  In that
> case, your changes should normally be managed by the higher level SCM, and
> the local SCM will be pull-from-upstream only, until your patches
> get accepted.

VC-dired should use only one backend for all the files in it.  So opening
VC-dired on the higher-level dir will naturally indicate that that is the
backend to use from there.  Regarding the backend to use in the file's
buffer, Emacs cannot know what to choose, so the choice has to be somewhat
arbitrary, but hopefully (as dhruva points out) changeable by the user (the
user can always use C-x v b later on).


        Stefan