[darcs-devel] nolinks argument

[Kevin Quick]

Now that I understand better, I think your proposal could be
interesting. Give me a day or so to investigate this alternative.

-KQ

On Mon, 9 Jul 2007 20:10:14 +0200, "Eric Y. Kow" <eric.kow at gmail.com>
wrote:

> Well, let me refine my proposal before we decide anything.
>
> > * I would prefer not splitting out the uses and having two different
> > copying routines at the base level though (although I don't feel
> > strongly about this).  My reasons:
>
> >    + I dislike having two ways of doing things.  Sometimes it's
> > appropriate, but I'm not sure that the distinction is strong enough
> > in this case to justify separate functions.  The disadvantage of
> > two different ways is that the programmer has to choose (if they
> > are even aware that there's a choice).
>
> I was thinking that we could mirror the copy/clone distinction and have
> a function cloneFileOrUrl.  To be honest, I can't tell if it's uglier to
> have two similar looking functions modulo copy/clone, or to make them
> thin wrappers around a parameterisable copyOrCloneFileOrUrl.
>
> Moreover, I believe copyFileOrUrl has a dangerously misleading name,
> because it does not make clear the fact that file could potentially be
> linked.  The result of this is that we one day 'copy' a file, modify the
> copy, finding to our dismay that we have also modified the original!
> Perhaps it is worth renaming the copy functions, or at least documenting
> them so that the point is made clear.
>
> >    + I think applying --nolinks to cases where it's not needed
> > (temporary fetches) is not harmful in any way except a (small?)
> > performance penalty.  In fact, using --nolinks implies that the user
> > is less concerned about performance than other issues (as long
> > as the performance reduction isn't egregious).
>
> I agree that it's likely not harmful.  It was basically the splatter
> I was worrying about.
>
> >     + It still requires passing the [DarcsFlag] options down through
> > all the intervening code to tell the link-possible code what to do.
> > You're analysis is correct: most of the changes just involved getting
> > [DarcsFlag] passed down deep enough, which caused the "splatter" effect
> > you noted below.  Perhaps there would be less splattering with two
> > different functions... if folks feel strongly enough I can investigate
> > this, but I couldn't tell you off the top of my head.
>
> I don't think this is quite right.  The idea is that neither
> copyFileOrUrl nor cloneFileOrUrl would require [DarcsFlag].
> Consequently, we would not have to modify functions like fetchFilePS.
> It would be up to copy_repo_patches to decide when to use one or
> the other.
>
> >     + Having two different functions would require a more intrusive
> > change in the darcs internals to implement... providing me a much
> > greater opportunity to break things.  :-)
>
> I think you might agree that my refined proposal is not so intrusive
> after all.
>
> > * Regarding your auto-detection thread: I could see usefulness in only
> > making links for files you own, but it still wouldn't solve the
> > dev/release policy scenario I described, and I think there's still
> > usefulness in allowing links to other people's repos.
>
> Well, it is a separate issue, as you have pointed out.
>
> > It might be useful though, either changing the --nolinks flag to
> > --links= {yes,owner,no} and/or some sort of darcs prefs or environment
> > variable.  If there's enough interest, I could look into implementing
> > this but I'd like more feedback on how people would like it to be
> > indicated, and I'd like to implement it as a separate, additional
> > patch following the --nolinks patches (assuming they are accepted).
>
> I suppose.  Although if you were to have a three-way setting, I would
> rather --links=owner be the default than --links=yes.  I'm rather
> skeptical as to the usefulness of links to other people's stuff, but you
> should ask somebody wiser and more experienced what they think.
>
> Personally, I'm interested, as I know some (highly intelligent)
> non-darcs-savvy users on a NFS share.  It is a shame for them to
> experience weird things happening because they gave the whole
> darcs thing a try.
>
> > * Eric, I think you are also correct in that only darcs get is actually
> > affected by --nolinks.  This seems to be because push/pull will read
> > the patches into memory, perform various commutation analysis and
> > whatnot, and then write them as new files to the output repository.
>
> I'm not sure what to think of this.
>
> I would be inclined to taking the arguments out, and adding back should
> the performance enhancements be made.  I appreciate the need for
> consistency.  I just worry that it might mislead the user in building
> the wrong mental model of darcs (albeit not fundmentally wrong as darcs
> could do it in principle).
>
> > OK, enough blathering on my part.  Please let me know if you'd like me
> > to refactor --nolinks to use two separate low-level copy routines, and
>
> I'd like you to take my refined proposal into consideration first, and
> then get back to me.
>
> > also if (and how) you'd like me to look at linking only owner files (or
> > anything else you'd like me to change for this patch).
>
> I consider the linking-owner-files thing to be a completely separate
> issue.  I would be pleased if you volunteered, but it will not affect my
> decision on your --nolinks code.
>
> All the best,
>
> --
> Eric Kow                     http://www.loria.fr/~kow
> PGP Key ID: 08AC04F9         Merci de corriger mon français.
>


--
--
Kevin Quick
quick at org after sparq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-devel/attachments/20070710/dde5135c/attachment.pgp