Matthieu Moy <[EMAIL PROTECTED]> writes: >> Even without using Gnus and DVC, it is still *far* easier to apply a >> diff file than to figure out what RCS-specific command to use to apply >> the patch. > > In Darcs, you'd have to type something like "| darcs apply", and I can > hardly think of something *far* easier than this.
Well, everything changes once an RCS implements sending and receiving changesets of some sort via email, like Darcs. Then it's usually preferable to use the native methods. Though it might be nice to keep around a separate command that sends a diff file, if one is locally using Darcs but upstream isn't. > And as a former maintainer of Xtla and DVC, I _do_ care about being > able to manage the list of unmerged patches : what about this old > mail ? did I already merge it ? Oh, did someone else merge it ? I'm > using a version control system to get an immediate answer to those > questions, and plain patches make my life harder with it. I guess you have a point. >>> 4) What patch do you send if your current branch contains merges from >>> upstream, which themselves have not yet be merged ? >> >> I think this somewhat misses the point of sending a patch via email. >> Regular contributors do not send patches over email -- they generally >> create and publish their own repositories instead. > > Hmm. I see regular contributors posting bundles on bazaar-ng's mailing > list regularly. Then the bundle is reviewed, discussed, and merged in > mainline. Right, I was only talking about RCS's that don't have a native method to send and apply patches from email. >> The people who use the email interface (and I speak as one of the >> few known users of this interface) use it because it is a quick and >> easy way to contribute. I don't care about metadata. I don't care >> about it applying it to multiple branches -- I only target the patch >> against the main contributor's branch. Once it gets into his branch, >> it's trivial for others to merge. > > You missed my point. > > Suppose you commit a first revision in your branch, doing > > [snip] > > It isn't easy to do indeed. The best solution I know is to merge from > upstream again, and then to send the patch from upstream to your local > branch. But you probably want a tool that does this for you ... If you're doing commits, you've already got a private repository. My bzr-submit code (and related usage patterns) assume that you *don't* have a private repository: you basically just use upstream's version. It assumes that you don't commit or record any changes that you make -- only email them. So does the old tla patch submission code, for that matter. If we want to address the case you bring up, we should tie it into dvc-changelog by adding a command that sends marked patches via email to a particular email address. Perhaps we could share some settings with these hypothetical routines, however, like mapping branch nickname to email address. > I've just checked for darcs, no, it's not compatible with diff. So, > here, the _one_ advantage of plain patch is that you can use Darcs > locally, and submit to a non-darcs projet. > > But please, don't encourrage people to send plain patches to a darcs > user when you can use darcs. OK, I'm starting to be convinced that we should use backend-specific changesets for emailing patches when the RCS itself can make and apply them. Maybe we should additionally keep a command or keybinding around that sends diff-style patches, though, to handle the case of using Darcs locally, but not upstream. > The bundle code is in bzr.dev, unreleased, but still relatively > stable. > > There should be more soon about sending them by email easily : > > http://bazaar-vcs.org/SubmitByMail Hmm ... is "bzr branch" substantially different than "bzr get", which Stefan used in his instructions? I don't even see the latter on the output of "bzr help commands". -- Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/ Interests: Emacs Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net /` |\ | | | IRC: mwolson on freenode.net: #hcoop, #muse, #PurdueLUG |_] | \| |_| Project involvement: Emacs, Muse, Planner, ERC, EMMS
pgpDvU3QCMgn3.pgp
Description: PGP signature
_______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
