--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--
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
