Customizing the VC backend order

Customizing the VC backend order

[dhruva]

Hi,
 i am trying to have mercurial as the first VC backend to be tried
before falling back on CVS (and the rest). I tried modifying the order
in "vc-handled-backends" in my dotemacs file. That does not help. I
really need this to be able to work completely from emacs, any help in
this regard is appreciated.
 Another query: When we specify a backend, does the case matter?
Example, HG and Hg, are the equivalent?

with best regards,
dhruva

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: Customizing the VC backend order

[Stefan Monnier]

>  I am trying to have mercurial as the first VC backend to be tried before
> falling back on CVS (and the rest).  I tried modifying the order in
> "vc-handled-backends" in my dotemacs file.

That *should* work.

> I really need this to be able to work completely from Emacs, any help in
> this regard is appreciated.

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).

>  Another query: When we specify a backend, does the case matter?
> Example, HG and Hg, are the equivalent?

I think they're not equivalent.  But I couldn't tell you offhand how it
would change things.


        Stefan

Re: Customizing the VC backend order

[Stephen J. Turnbull]

Stefan Monnier writes:

 > 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!

While I see the logic behind your suggestion, I think what should be
done is to ask the user.  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.

Re: Customizing the VC backend order

[Stefan Monnier]

>> 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

Re: Customizing the VC backend order

[dhruva]

Hi,

On 8/10/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > falling back on CVS (and the rest).  I tried modifying the order in
> > "vc-handled-backends" in my dotemacs file.
>
> That *should* work.

I tried with only the following two lines in my dotemacs
(load "vc-hg")
(setq vc-handled-backends (nconc '(Hg) (delq 'Hg vc-handled-backends)))

$emacs -q -l dotemacs

I still see CVS selected over Hg though the file is under CVS (pulled)
and Mercurial (Hg, with edits).

I just wanted to make sure if I am doing the right thing.

-dhruva

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: Customizing the VC backend order

[Stefan Monnier]

>> > falling back on CVS (and the rest).  I tried modifying the order in
>> > "vc-handled-backends" in my dotemacs file.
>> 
>> That *should* work.

> I tried with only the following two lines in my dotemacs
> (load "vc-hg")

What's that for?

> (setq vc-handled-backends (nconc '(Hg) (delq 'Hg vc-handled-backends)))

Why `nconc' rather than `cons' (or `append')?

> $emacs -q -l dotemacs

> I still see CVS selected over Hg though the file is under CVS (pulled)
> and Mercurial (Hg, with edits).

> I just wanted to make sure if I am doing the right thing.

Does C-x v b allow you to switch to the Hg backend?


        Stefan

Re: Customizing the VC backend order

[David Kastrup]

dhruva <dhruvakm@gmail.com> writes:

> Hi,
>
> On 8/10/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> > falling back on CVS (and the rest).  I tried modifying the order in
>> > "vc-handled-backends" in my dotemacs file.
>>
>> That *should* work.
>
> I tried with only the following two lines in my dotemacs
> (load "vc-hg")
> (setq vc-handled-backends (nconc '(Hg) (delq 'Hg vc-handled-backends)))

Yikes!!!!!  Please _never_ use nconc unless you have a license to do
so.  Do you know what the last line will do when executed more than
once?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Customizing the VC backend order

[dhruva]

Hi,

On 8/10/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> >> > falling back on CVS (and the rest).  I tried modifying the order in
> >> > "vc-handled-backends" in my dotemacs file.
> >>
> >> That *should* work.
>
> > I tried with only the following two lines in my dotemacs
> > (load "vc-hg")
>
> What's that for?

To make sure it is loaded.

> > (setq vc-handled-backends (nconc '(Hg) (delq 'Hg vc-handled-backends)))
>
> Why `nconc' rather than `cons' (or `append')?

Very limited lisp/elisp knowledge :-(

>
> Does C-x v b allow you to switch to the Hg backend?
>

No, it does not work. I get a message "No other backend to switch to"

with best regards,
dhruva

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: Customizing the VC backend order

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> dhruva <dhruvakm@gmail.com> writes:
>
>> Hi,
>>
>> On 8/10/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>> > falling back on CVS (and the rest).  I tried modifying the order in
>>> > "vc-handled-backends" in my dotemacs file.
>>>
>>> That *should* work.
>>
>> I tried with only the following two lines in my dotemacs
>> (load "vc-hg")
>> (setq vc-handled-backends (nconc '(Hg) (delq 'Hg vc-handled-backends)))
>
> Yikes!!!!!  Please _never_ use nconc unless you have a license to do
> so.  Do you know what the last line will do when executed more than
> once?

Well, at least when you actually _read_ the line once.  So try the
following example.  Can you figure out what happens?

(setq xxx (copy-sequence vc-handled-backends))
(dotimes (i 3)
  (setq xxx (nconc '(Hg) (delq 'Hg xxx))))
xxx

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Customizing the VC backend order

[Stefan Monnier]

> No, it does not work. I get a message "No other backend to switch to"

So the problem is not the ordering but the fact that vc-hg.el doesn't
recognize the file as being under Hg's control.


        Stefan

Re: Customizing the VC backend order

[Vinicius Jose Latorre]

David Kastrup wrote:
> [...]
> Well, at least when you actually _read_ the line once.  So try the
> following example.  Can you figure out what happens?
>
> (setq xxx (copy-sequence vc-handled-backends))
> (dotimes (i 3)
>   (setq xxx (nconc '(Hg) (delq 'Hg xxx))))
> xxx
>   



Hummm, interesting, see:

;; 1 time
M-:
(progn
   (setq xxx (copy-sequence vc-handled-backends))
   (setq xxx (nconc '(Hg) (delq 'Hg xxx)))
   xxx)
RET
==> (Hg RCS CVS SCCS Bzr Git Arch MCVS)


;; 2 times
M-:
(progn
   (setq xxx (copy-sequence vc-handled-backends))
   (setq xxx (nconc '(Hg) (delq 'Hg xxx)))
   (setq xxx (nconc '(Hg) (delq 'Hg xxx)))
   xxx)
RET
==> (Hg RCS CVS SCCS Bzr Git Arch MCVS)


;; 3 times
M-:
(progn
   (setq xxx (copy-sequence vc-handled-backends))
   (setq xxx (nconc '(Hg) (delq 'Hg xxx)))
   (setq xxx (nconc '(Hg) (delq 'Hg xxx)))
   (setq xxx (nconc '(Hg) (delq 'Hg xxx)))
   xxx)
RET
==> (Hg RCS CVS SCCS Bzr Git Arch MCVS)


;; dotimes
M-:
(progn
   (setq xxx (copy-sequence vc-handled-backends))
   (dotimes (i 3)
     (setq xxx (nconc '(Hg) (delq 'Hg xxx))))
   xxx)
RET
==> INFINITE LOOP!!!! ?

Re: Customizing the VC backend order

[Johan Bockgård]

David Kastrup <dak@gnu.org> writes:

> dhruva <dhruvakm@gmail.com> writes:
>
>> (setq vc-handled-backends (nconc '(Hg) (delq 'Hg vc-handled-backends)))
>
> Yikes!!!!!  Please _never_ use nconc unless you have a license to do
> so.

Ditto for delq.

    (get 'vc-handled-backends 'standard-value)
      =>
      ((quote (RCS CVS SVN SCCS Bzr Git Hg Arch MCVS)))

    (delq 'Hg vc-handled-backends)

    (get 'vc-handled-backends 'standard-value)
      =>
      ((quote (RCS CVS SVN SCCS Bzr Git Arch MCVS)))

-- 
Johan Bockgård

Re: Customizing the VC backend order

[dhruva]

Hi,

On 8/10/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > No, it does not work. I get a message "No other backend to switch to"
>
> So the problem is not the ordering but the fact that vc-hg.el doesn't
> recognize the file as being under Hg's control.

Thank you for all the help. I had made the following mistake in my
windows setup. I have mercurial built as an executable and added that
folder in the PATH variable (as required). The mistake was enclosing
the folder in double quotes.

- I have mercurial installed under: E:/Program Files/hg (yes, folder
with a space!)
- I added in the PATH as: set PATH="E:/Program Files/hg";%PATH%
- From the command shell, I am able to invoke mercurial. Implies that
it is in path
- I use "which.exe" (from MinGW), it fails to find the "hg.exe"!
- I am not setting the path with out the double quotes and "which.exe" finds it
- Mercurial now works as required. The order in the vc-handled-backend
list is honored

I thought of putting in the details here as someone else may stumble
upon the same problem!
Also, I modified my dotemacs (eliminating nconc):
(setq vc-handled-backends (cons 'Hg (delq 'Hg vc-handled-backends)))

Not so important/relavent: I went through the 'C' implementation of
'nconc'. I find it concatenates 2'nd to the 1'st, 3'rd to the 2'nd...
N'th to the (N-1)'st and returns the 1'st list. I wonder how it can
get into an infinite loop. Any clarification here would help me
understand 'nconc' and 'C' better (as I find this a natural way to
concatenate lists. I would have probably done in the reverse order and
could eliminate the need for storing the first argument in the
function and just return the first argument)

with best regards,
dhruva

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: Customizing the VC backend order

[Andreas Schwab]

dhruva <dhruvakm@gmail.com> writes:

> Not so important/relavent: I went through the 'C' implementation of
> 'nconc'. I find it concatenates 2'nd to the 1'st, 3'rd to the 2'nd...
> N'th to the (N-1)'st and returns the 1'st list. I wonder how it can
> get into an infinite loop.

nconc can generate circular lists.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Customizing the VC backend order

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> dhruva <dhruvakm@gmail.com> writes:
>
>> Not so important/relavent: I went through the 'C' implementation of
>> 'nconc'. I find it concatenates 2'nd to the 1'st, 3'rd to the 2'nd...
>> N'th to the (N-1)'st and returns the 1'st list. I wonder how it can
>> get into an infinite loop.
>
> nconc can generate circular lists.

Which is what happens on the second iteration.  And on the third
iteration, nconc gets stuck trying to find the end of the circular
list in order to append to it.

nconc is _destructive_ on all but its last element.  So you need to
provide it with a list that you know you won't need later anymore.

You can write
(nconc (list 'Hg) something)
without any problem, since you generate a new list on any call.  And
you can even write verbatim
(nconc '(Hg) something)
as the reader generates a new list to nconc whenever it reads the
expression.  But as soon as you stick this into a loop or function or
anything else, the reader creates _one_ static list when he reads the
above expression.  And this list is _reused_ after it gets manipulated
with nconc.

Lisp is a dynamic language: all its programs are lists themselves, and
can be manipulated like lists.  And that is what you do here.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Customizing the VC backend order

[David Kastrup]

Please keep the list copied as long as there is nothing involved
concerning only myself.

dhruva <dhruvakm@gmail.com> writes:

> On 8/11/07, David Kastrup <dak@gnu.org> wrote:
>> dhruva <dhruvakm@gmail.com> writes:
>> Oh no, it is not an optimization.  Lisp programs _are_ lists.  It
>> would be a bug if a quoted list inside of a Lisp program would be
>> magically replaced by something new every time the program was run.
>
> Since lists are mutable (from the PYTHON usage), I must be able to
> do an inplace deletion and insertion in a list.

Why would you want to do _inplace_ deletion or insertion on '(Hg)?
That does not make sense, unless you want the meaning of '(Hg) to
change.

> Going back to my vc-handled-backends list, if I can inplace delete
> "Hg" entry and prepend it with "Hg", I need not call a setq.

There is neither reason nor usefulness in not calling setq: setq does
not copy lists.

> Can this be done, inplace modifications?  Apologies for asking too
> much from you, if you point me to a low level document, I will put
> in efforts to learn.

(info "(elisp) Rearrangement")
aka
<URL:info:elisp#Rearrangement>

explains this quite carefully.

What you probably wanted was something like

(setq vc-handled-backends (cons 'Hg (delq 'Hg vc-handled-backends)))

This destructively changes the old vc-handled-backends (unless it does
not contain Hg at all, or only as the first element) and prepends Hg.
As long as nobody kept the original (not a copy) of the old
vc-handled-backends (which will get its Hg deleted without getting
anything prepended), this is perfectly fine.

What isn't, is destructively manipulating '(Hg).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Customizing the VC backend order

[dhruva]

Hi,
On 8/11/07, David Kastrup <dak@gnu.org> wrote:
> What isn't, is destructively manipulating '(Hg).

I get the point. My intention was to modify the vc-handled-backends
inplace and the delq and cons combination does that. Thanks for the
patience.

-dhruva

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!