[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sat, 12 Aug 2017 20:43:50 +0300
> From: Jonas Bernoulli <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> Date: Sat, 12 Aug 2017 19:26:15 +0200
> >> > A revisioned filename is something like "/path/to/file@@revision".
> >> > "revision" could be a revision like "81656add81", a branch like
> >> > "scratch/kqueue", or a tag like "emacs-19.34". Of course, the syntax
> >> > could be changed.
> >> I would prefer /path/to/repo/@git:REVISION:path/to/file. I don't have
> >> a strong opinion about what the magic cookie should look like, but I
> >> think it should be inserted at the root of the working tree.
> > That doesn't scale to VCSes which keep separate versions for
> > individual files.
> How so? Wouldn't my scheme just look like:
> instead of
> when trying to stay as close the internals of that <vcs>?
Well, for starters, it will defeat the completion machinery, or at
least make it much more complicated.
> Also isn't that an implementation detail and users of <vcs> still
> think of "/path/to/top" as "the repository"? If that is so then
> what should it matter that <vcs> spreads the history files across
> the repository instead of putting them into a dedicated control
FILE@@revision is not a history file, it is FILE as it looked like at
given VERSION. Where that information is kept is beside the point.
As I'm sure you understand, so I guess I don't really see the point
you are making here.
> > Michael's scheme does support such VCSes. For a
> > VCS like Git or Bazaar, Michael's scheme shouldn't get in the way, I
> > think.
> Maybe we could use different schemes for different vc systems.
That would be undesirable, I think.
> The revision is part of a virtual directory structure
Sorry, you lost me. What is that "virtual directory structure", and
how is it relevant to this issue?
> This is one way of accessing <blob> as stored in <branch>:
We are talking about abstractions, not about their Git implementation.
So why do we have to consider blobs?
> One example use case where the scheme that I propose would be nicer than
> the non-hierarchic one is "using find-file to open another blob from the
> same revision/tree".
I guess I'm so Git-ignorant that I don't even understand what that
means. Maybe I shouldn't be part of this discussion.