[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Access to repository-side files in version control repositories

From: Michael Albinus
Subject: Re: Access to repository-side files in version control repositories
Date: Mon, 03 Sep 2012 20:39:30 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Randy Yates <address@hidden> writes:

Hi Randy,

>   a) Directly get an arbitrary repository file into a buffer using a
>   standard syntax using the visit-file mechanism. That means that I
>   may not even have a wc of the repo checked out at all. Note that I
>   just want to see the file (search it, copy it, etc.) in this scenario,
>   not run a diff on it.
>   b) Diff arbitrary repository-side files WITHOUT HAVING TO FIRST EDIT
>   ANY WC FILE (by specifying the repository, file, and version). In
>   fact, I may want to diff two repository-side files that reside in
>   different repositories!
> I see now vc.el provides some of this functionality, albeit not via a
> standard visit-file mechanism. (I misinterpreted that part of the ediff
> info page on this.) But I still think the ability to c-x f a
> repository-side file brings a good bit more flexibility/capability to
> emacs and its packages. 

Got it. Yes, this might be useful.

But I don't believe, that Tramp shall be the primary target of that
request. Different version control systems use different repository
formats. The logic, how to retrieve a file revision from a given
repository, belongs to the different vc backends.

vc shall be extended by a unique interface to retrieve a named revision
from a repository, and to compare different revisions, w/o having a
working copy. Implementation of that functionality is the duty of the
respective vc backends.

I'll be happy to support access to the remote repositories via
Tramp. But I bet, there's no need to extend Tramp for this. If I'm
wrong, we still could work on Tramp.

I recommend you to file an Emacs change request, via "M-x report-emacs-bug".

Best regards, Michael.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]