[darcs-users] New argument for symlink support

Max Battcher me at worldmaker.net
Wed Dec 2 07:12:15 UTC 2009


Petr Rockai wrote:
> Jason Dagit <dagit at codersbase.com> 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


More information about the darcs-users mailing list