If the VCS gives each file an 'internal' id that is:
- unique across all repos; and
- persistent wherever the file goes, or however its location/name
changes.
Although this sounds alluring from the implementation perspective, I worry
about the user perspective on something like this, because you are
deemphasizing the main framework under which they (and all the other
tools) have been operating. This may turn out to be an advantage, but it
is something to consider.
I'm suggesting the file id be the ppid of when it got added, to help
with the
book-keeping. (I'm assuming this can also tell us in which repo the file
started life.)
For your purposes wouldn't any guid suffice? I'm not sure that the source
repo is useful.
This discussion is all by way of warming-up for dealing with
hunk changes, where we need to implement some sort of line-id, and
detect line
movements.
I'm not sure line mapping follows from file mapping. The file tends to be
a long-lived entity even though it's contents morph over time/patches. A
particular line doesn't really have a "rename" operation; in the absence
of context a new version simply replaces the old at a fairly atomic level
(ie. there are no sub-operations could be mapped from the old line to the
new line as is the case for a file).
That said, I think there would be great value to a VCS that is
context-aware (as has been discussed previously in this thread) and
perhaps degrades to line-oriented management if no context can be
determined. Two brief examples:
original: if (ready && remaining < 10) {
change1: if (!ready && remaining < 10) {
change2: if (ready &&
remaining < 10)
{
For a C-style context, it seems reasonable that change1 and change2 should
not conflict. The second example:
original: if (remaining < 10) {
x();
y(remaining);
}
change1: if (ready) {
if (remaining < 10) {
x();
y(remaining);
}
}
change2: if (remaining < 10) {
x();
y(remaining, 10);
}
Again, it would be wonderful if these two changes didn't conflict during a
VCS merge (and more specifically if the VCS knew the language context was
whitespace insensitive like C and therefore the additional indentation in
change1 wasn't a conflict with any other change in the region).
Of course, Stephen Turnbull has already provided a counter-example in this
email thread showing the indeterminism even in a context-aware system, but
since we're having a fairly open discussion I thought I'd toss these
thoughts into it. :-) Neither of the above is possible with a
line-oriented scenario like L/S/L but Eelco Lempsink's thesis makes for an
interesting read in this area: http://eelco.lempsink.nl/thesis.pdf
> Possibly we could expose the non-equivalence to the programmer even
> before
> pulling the hunk change, by the VCS linking B's file G to F to branch
A,
> but not linking C's file G.
Explicit dependencies like that (which are normally impossible or at
best
over-restrictive in darcs because it forces explicit repo
relationships) ...
Could you explain a bit more what you mean by 'explicit repo
relationships',
and what's bad about them?
I (mis?)understood your "linking" above to be recording in repo B a
reference to repo A. Thus A would be explicitly referenced in B. The
normal repo relationships in darcs are more ephemeral and outside of a
push/pull the only relationship is a "suggestion" for the default of the
next push/pull operation. The explicit A reference in B would require the
persistence and accessibility of A while working in B and make it
difficult to recognize C cloned from A as an equivalent for that explicit
reference.
Pulling a patch from one repo to another sets up a relationship anyway
(so I
understand?). One purpose of that is to detect duplicates. (That is,
dependen-
upon patches already pulled to the target -- from Owen's description.) I
don't
think anything about ppid-as-file-id gets in the way of repos working
standalone; that is until you want to pull/merge patches -- at which
point
surely a repo relationship and restrictions is exactly what you want(?)
Only inasmuch as the relationship is determined in the moment of the
push/pull and not persisted outside of that action. Once the action is
completed, there is no explicit relationship between the repos. They may
contain common patches which forms an implicit relationship, but they must
re-discover this on the next push/pull between the two (at least for
darcs).
I don't know if I'm helping the discussion: it seems we are exploring
theoretical VCS infrastructure so I'm enjoying our semi-abstract discourse
and I may not be contributing to your goal. If that's the case, please
excuse my maunderings. :-)
--
-KQ
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
