[darcs-users] [patch39] darcs fetch
Dan Pascu
dan at ag-projects.com
Wed Nov 25 07:39:16 UTC 2009
That clarifies it, thank you. My only remaining comment is that I find
these commands clearly defined and consistent with the rest of the
darcs UI, but at the same time I consider them to have a niche
usefulness. I do not find a use for them in my workflows, but I'm sure
other people will. Now regarding if there is a better alternative to
them, I do not know. Since I do not see a use for them myself, I
cannot imagine a better way of doing something I do not do ;). This
proposal seems reasonable to me.
On 24 Nov 2009, at 17:33, Florent Becker wrote:
> --nextPart1323724.XxME5LlBlx
> Content-Type: Text/Plain;
> charset="iso-8859-15"
> Content-Transfer-Encoding: quoted-printable
>
> Hi list, hi Dan,
>
> and thanks for the review. Here come my answers.
>
> The executive version is: fetch is for retrieving and *naming* a set
> of patches into a file without applying them. You can then inspect
> them in =
> a=20
> text editor, as you would with a sent bundle, and apply them, not
> necessari=
> ly=20
> all at once.
>
>>
>>> If you're interested, I'll start be requesting on list that you
>>> serve
>>> as Grumpy Old Man for Florent's recent patch39.
>>
>>
>> Since you asked, I will not leave you empty handed, so I will give
>> my =20
>> input on patch39. Again I cannot read haskell code, so what I say
>> is =20
>> entirely based on the comments that accompanied the code.
>>
> Ok
>
>> I agree with Florent that fetch and unapply are 2 commands that are
>> =20
>> easily learnt and with clear semantics. From this point of view I
>> see =20
>> no reason against them.=20
>
> Good
>
>> But from the user perspective, while Florent =20
>> calls them "very useful", I could not imagine a single use case for
>> =20
>> them. Maybe if I'm told one, I will have an a-ha moment and see the
>> =20
>> light. But right now I do not really understand how fetch can be =20
>> useful. There is no description how one can inspect a patch that
>> was =20
>> fetched to _darcs/pacthes but it was not applied. Even right now I
>> =20
>> still have patches that are in _darcs/patches but I cannot access =20
>> (patches I unrecorded/obliterated/amend-recorded). Or maybe he
>> plans =20
>> to store them in a different place.=20
>
> Yes, that is the point, which i'm sorry if I did not make clear
> enough, the=
> y=20
> are stored in a bundle file, not in _darcs/patches.
>
> Contrarily to hg's and git's(?) fetch, darcs fetch gives you the
> patches in=
> a=20
> simple bundle in the current directory (as does send -o),
> *not in _darcs/patches*. This means that it does not modify the state
> of the local repository. It offers you the patches for inspection by
> puttin=
> g=20
> them into a file with the name of your liking.
>
> You can then inspect that bundle using a text editor or whatever tool
> you want. You can also keep it for later application, maybe in some
> other=20
> related repository, maybe not applying the patches all at once.
>
>> But then how is this different =20
>> than having a patch cache. Right now I can pull a patch, then
>> inspect =20
>> it with darcs diff or darcs changes, then obliterate it. Next time
>> I =20
>> pull it it will take it from the cache so no extra download will be
>> =20
>> necessary. How does darcs fetch improve on this?
>
> It does not improve download performance at all! (Even if doing a
> darcs fet=
> ch=20
> has the desirable side-effect of putting the patches in cache,
> that's not t=
> he=20
> point of the command). However, you can fetch
> several patches at once, and give a name to that set of patches.
> Suppose fo=
> r=20
> instance that you want to port a feature from David's darcs to your
> own dar=
> cs=20
> repository. The two repositories may have diverged, so the merge is
> going t=
> o=20
> be a bit complicated. Currently, you have three solutions: either
> you do a=
> =20
> pull, select all the relevant patches and then you have to solve all
> the me=
> rge=20
> problems at once. Or you pull the patches one by one, but you need
> to have=
> =20
> network connectivity for each patch, so you can't do that on a
> train, and y=
> ou=20
> have to redo the work of sorting the remote patches every time.
> Finally, yo=
> u=20
> can get your own repository into a new copy, pull all the remote
> patches in=
> to=20
> that copy, then pull from the copy to your work repo. Then you have
> to use=
> =20
> darcs changes to review the patches, and you have one more
> repository. If t=
> he=20
> patches are small with respect to the size of the project, you use
> more dis=
> k-
> space than you really should. With fetch, you just fetch, select the
> patche=
> s=20
> you want, then use darcs apply -i fetched-patches.dpatch at your
> leisure. I=
> t's=20
> like the last use case, except that it's more lightweight.=20
>
> It scales better (at least for me) to have throwaway bundles for
> sets of=20
> patches which I may or may not want to apply than to have throwaway
> repos f=
> or=20
> each such set of changes. Our workflow where we review sent bundles
> is doab=
> le=20
> because we have send, and with fetch, we can extend it to pull-
> requests: if=
> I=20
> want to examine a set of patches from someone's repo, i'd much
> rather have =
> a=20
> bundle representing exactly the patches i want to pull than either
> have to =
> do=20
> remote invocations of darcs changes before i pull or having to
> create a ful=
> l=20
> repo every time. If I use the cache for that purpose, then I lose
> track of =
> the=20
> set of patches I'm working with everytime (what if they don't have a
> cohere=
> nt=20
> naming?)
>
>> I see a similar problem with unapply. What is the reason to
>> preserve =20
>> the patch in _darcs/patches if I do not have a way to inspect it?
>> Also =20
>> what is the reason to preserve it in _darcs/patches if it is
>> preserved =20
>> in the cache anyway? Maybe there is something obvious I'm missing,
>> but =20
>> the description I red didn't mention anything about this. Even if =20
>> there is a way to inspect the patches, how do these commands
>> improve =20
>> over the existing obliterate + patch preserved in the cache.
>>
> They allow the user to be unaware of the cache (or not to have one).
> The=20
> patches are given to you in a named bundle. That way, you keep them
> togethe=
> r=20
> for later use. For instance, suppose you implement some feature in a
> serie =
> of=20
> 10 patches. Then you realize that it has a problem which makes the
> feature=
> =20
> undesirable for the moment (say, you have to wait for a new version
> of libf=
> oo=20
> so that some function there is fixed before your feature works at
> all). You=
> can=20
> then unapply the 10 patches to get a feature-waiting-for-
> libfoo.dpatch bund=
> le.=20
> You keep this bundle and apply it whenever libfoo2 gets released.
> Without=20
> unapply, you need to keep a full repository feature-waiting-for-
> libfoo. You=
> =20
> might even want a repository without-feature-waiting-for-libfoo so
> that you=
> =20
> can use pull --complement to get exactly the right set of patches.
> That's t=
> wo=20
> full repositories versus a bundle with 10 patches. Another example
> would be=
> if=20
> you wanted to keep the patches for reference, for example as an
> explanation=
> as=20
> to why some thing is not doable. In that case too, it saves you from
> keepin=
> g=20
> two repositories, and the bundle shows you where exactly the problem
> is (ju=
> st=20
> open it in your text-editor).
>
>> What I would really find useful however would be a darcs diff --
>> patch =20
>> "title" remote-repo, i.e. a way to see a patch that is in a remote
>> =20
>> repository. I prefer diff over whatsnew or changes --verbose,
>> because =20
>> I can get a unified or context diff that shows me the context
>> around =20
>> the change. whatsnew or changes --verbose are harder to read in the
>> =20
>> context. darcs changes already can do this with the --repo
>> argument. =20
>> So maybe if we could add the --repo argument to diff then we would
>> get =20
>> the ability to check remote patches and something like fetch/
>> unapply =20
>> may become unnecessary.
>
> I think these are orthogonal, and we should try to make changes -i a
> supers=
> et=20
> of diff in that case.
>>
>> P.S. keep in mind that I say all this because I do not see any
>> obvious =20
>> use for these two commands, that I cannot already do using the
>> cache. =20
>> Maybe I'm just missing the obvious.
>
> Note also that these commands allow the user to be unaware of the
> cache, wh=
> ich=20
> is a good thing. The cache is currently overloaded between download-
> speed=20
> improvement and a collection of unapplied patches. This means that
> erasing =
> the=20
> cache can destroy valuable information, which is not what a cache is
> suppos=
> ed=20
> to do. If you use fetch and unapply consistently rather than relying
> on the=
> =20
> cache, then you can always get rid of your cache, should you need
> to. There=
> 's=20
> no reason I should have to keep every patch i have ever downloaded,
> so that=
> I=20
> can keep some patches which I do not want to see applied yet.
>
> Hope this helps,
>
> =46lorent
>
> --nextPart1323724.XxME5LlBlx
> Content-Type: application/pgp-signature; name=signature.asc
> Content-Description: This is a digitally signed message part.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEABECAAYFAksL/J0ACgkQTCPcDztjGo7eogCeMeaTDT5pUn0DXqqEKTEi9jtt
> aCQAn2X/UpncO4+G9t1CIi5vh98+Ubv/
> =Jo+M
> -----END PGP SIGNATURE-----
>
> --nextPart1323724.XxME5LlBlx--
> _______________________________________________
> darcs-users mailing list
> darcs-users at darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-users
--
Dan
More information about the darcs-users
mailing list