[darcs-devel] nolinks argument

Eric Y. Kow eric.kow at gmail.com
Mon Jul 9 11:10:14 PDT 2007


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-devel/attachments/20070709/48461f25/attachment.pgp


More information about the darcs-devel mailing list