<br><br><div class="gmail_quote">On Tue, Dec 1, 2009 at 11:12 PM, Max Battcher <span dir="ltr">&lt;<a href="mailto:me@worldmaker.net">me@worldmaker.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">Petr Rockai wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Jason Dagit &lt;<a href="mailto:dagit@codersbase.com" target="_blank">dagit@codersbase.com</a>&gt; writes:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Can someone workout the rules for commuting symlink patches?  I think treating<br>
them as files which contain a path to where they point is a reasonable way to<br>
model them.<br>
</blockquote></blockquote>
&gt;<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
just a little (side)note: please don&#39;t do the mistake of introducing a<br>
new patch type for something that is adequately served by addfile and<br>
hunk patches. At least unless you want to repeat the setpref<br>
debacle. (It may be that addfile will need substituting, but definitely<br>
be wary of hunks.) Oh, and keep in mind that if we add a new patch type,<br>
we are making an incompatible darcs repository format (akin to the<br>
darcs-2 incompatibility, although arguably less severe).<br>
</blockquote>
<br></div></div>
Somewhat related to that point: if darcs were to add symlink<br>
(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.<br></blockquote><div><br>Queuing up several repository format changes and making them all &quot;go live&quot; at once seems reasonable.  Call it darcs-3 format if it makes you happier :)<br>
<br>But, I think the discussion of tokenization and if/which things should be queued is probably something that should be agreed up and decided outside of a feature request for symlinks.  Eg., make a feature request in round up (if there isn&#39;t already) hold a public discussion on the mailing list and involve the release manager.  It&#39;s a good discussion to have, but let&#39;s try to do it in a different thread, please.<br>
<br>Jason<br></div></div><br>