Petr Rockai wrote:
Jason Dagit <[email protected]> writes:
Can someone workout the rules for commuting symlink patches? I think treating
them as files which contain a path to where they point is a reasonable way to
model them.
>
just a little (side)note: please don't do the mistake of introducing a
new patch type for something that is adequately served by addfile and
hunk patches. At least unless you want to repeat the setpref
debacle. (It may be that addfile will need substituting, but definitely
be wary of hunks.) Oh, and keep in mind that if we add a new patch type,
we are making an incompatible darcs repository format (akin to the
darcs-2 incompatibility, although arguably less severe).
Somewhat related to that point: if darcs were to add symlink
(and/or hardlink?) tracking support the point in time where I think that
makes the most sense is alongside the tokenization of file names
proposed as a possibility on the roadmap.
(What I mean by the tokenization of file names is that point where files
themselves to darcs are represented in patch formats by some internal
token, such as a content hash-based name or psuedo-random GUID or what
have you, and then "instanced" to some literal file path.)
Since there would be a format change at that point anyway, it becomes a
good opportunity to contemplate symlink primitive patches, et al. I also
think that the tokenized file name concept particularly lends itself to
easier ideas of the representation of what a symlink might be.
Anyway, I hope that makes sense...
(Personally, I'm a moderate -0 on the whole issue... I've yet to need
VCS symlinks, but then I still use Windows often enough that symlinks as
a whole are rare in my day-to-day usage stories anyway.)
--
--Max Battcher--
http://worldmaker.net
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
