So the distinction is useful, but is it useful enough to be included
in Darcs, and hence impose an additional conceptual burden on all new
users? I don't have a strong opinion (I'd like David to make a call),
but it's certinly not useful enough to take up two good command names
such as ``darcs ignore'' and ``unignore''.
I think that for most projects this new feature would be downright hurtful and is just not the right way to go about what is needed. Most people should be recording their local changes using Darcs even if they are not going to send those changes back upstream. Otherwise, you have no history of your local changes and 99% of the time that does not make any sense.
If you are ONLY making local modifications (never sending anything back upstream), then this new feature is useless--you could just record your changes like normal and consider your entire source tree to be "ignored."
Furthermore, if you have local "ignored" changes in your source tree, and you want to send patches upstream from that source tree, then how do you know that the patches you want to send do not depend on your ignored changes? For most projects, the only way you can know reliably is to have a source repository without the ignored changes to test on. For example, I would never send patches for Darcs or GHC from a source tree with other changes in it--I could break the build and inconvenience everybody. To manage this, I use three repositories:
upstream: http://darcs.haskell.org/ghc
shared: ~/ghc-shared-changes
ignored: ~/ghc-local-changes
I pull changes from "upstream" into "shared" and I pull from "shared" into "ignored." "shared" contains all the patches that I want to send upstream, and "ignored" additionally contains all the patches that I do not intend to send upstream. Notice how I still have full history of my local changes. Also, notice that at any time I can change my mind and send some of my "ignored" patches upstream--to do so, I would send then to "shared," test them, and then send them to "upstream."
In summary, the functionality of the proposed feature is already available in a more powerful, more generally useful form, and the proposed feature would encourage bad practice (namely, sending untested patches), so I recommend that it not be added to Darcs. Instead, I think effort should be made to make working with three or more repositories easier.
Regards,
Brian Smith
_______________________________________________ darcs-users mailing list [email protected] http://www.abridgegame.org/mailman/listinfo/darcs-users
