Le mardi 24 novembre 2009 18:57:35, Max Battcher a écrit : > Florent Becker wrote: > >> 6. What are the alternative approaches to solving the same problem? Why > >> do we prefer this one? > > > > Other ways to do the same thing involve either relying on the patch > > cache, which is not darcsish and has interference with the possibility to > > clean it, or they use temporary repositories, which are heavyweight (if > > only because you need one working dir for each). > > I see this as more reason to get --no-working-dir sorted out, first.
Well, we can have fetch now, and it does come with the well-known bundle format, which guarantees immutability, instead of going for --no-working-dir, which could prove buggy. > Also, there is another clear alternative: > > 1. Grep the remote inventory for the patch hashes you want > 2. wget/scp the patches into the directory of your choice > This would not be sufficient: you would still have to commute the patches to be next to one another (which I have no idea how to do at that point of your scenario) and then put them together in a bundle. That's far from trivial, but you need it to be able to darcs apply. If you want to darcs pull instead, then you have to invent a repository format out of thin air… And grepping the remote inventory does not give you all the possibilities of --match (at least, not trivially). Neither does it give you interactive selection of patches. How do you distinguish between --match "touch myfile", and having myfile within the hunks, short of rewriting darcs' parsers? Also, fetch allows the user not to know about hashes. This is a great advantage of darcs when compared to git. > We fight to keep darcs using normal file transfer tools and open > greppable formats. This is in keeping with this goal: we get the same bundle file format which we use with send. It seems greppable enough for me. The file transfer is the same as in the rest of darcs, so there's no difference (unless you're advocating getting rid of push, pull, get and put which also encapsulate network transactions…) > and I, for one, am not convinced that the user stories > here are common enough to justify pretty commands with nice UI to do > what you can mostly do with existing file commands. > I know the user stories are not that common, but it makes sense for the command set to be more symmetric. And you do get something which is useful. Unapply is a regular source of frustration for me (it generalizes the recurrent "darcs stash" feature wish). Fetch allows a workflow which I'd like to have (1 select patches / 2 review them / 3 apply them carefully), and which is not very comfortable right now (you need to have quite a few throwable repositories). I recognize that fetch is a bit less necessary than unapply, given that you can get away with throwaway repositories instead of bundles. But I think it's largely worthy of having, given the amount of code necessary for fetch (which is almost nil, given that it could share a bit more code with send than it currently does, pending some cleaning in send). Florent _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
