Quoting Michael Olson <[EMAIL PROTECTED]>: > Matthieu Moy <[EMAIL PROTECTED]> writes: > > 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.
Of course, being able to send patches is a good thing. The typical case is when upstream uses a non-decentralized RCS, while you want a decentralized one (many people use bzr or used to use GNU Arch to track CVS projects. bzr is even implementing a method to access subversion branches directly). But this should be a workaround when you don't have a better way. > Right, I was only talking about RCS's that don't have a native method > to send and apply patches from email. They're becoming more and more rare, since Darcs showed how convenient it is ! bzr doesn't have te email interface yet, but most of the job is to have the bundles (alias changesets). Then, it's just a matter of computing the closest common ancestor so that you know which revision to bundle, and have the email interface itself. > 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. Then, I have good news for you : You _do_ have a local repository ;-). $ bzr get --help usage: bzr branch FROM_LOCATION [TO_LOCATION] aliases: get, clone [...] Whether you use get, clone or branch, you get a new, local branch, which at this moment is an exact copy of the remote one. You have nothing else to do to be able to commit, your local branch is already there. This is how bzr, hg, darcs, and I believe git work, and this is a fundamental difference with the GNU Arch model. In GNU Arch, you _had_ to create a local repository, and to explicitely create a branch, because one revision could have only one direct successor (the direct successor of a/c--b--v--patch-N has to be a/c--b--v--patch-(N+1), and it has to be unique), so you have to explicitely use "tag" or "branch" to create a branch. In bzr, each revision has a unique identifier which is roughly picked at random. So if two persons commit a successor for revision N in two copies of a branch, both get a revision N+1, with a different revision-id, in their own copy of the branch, and they can merge from each other. > 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. tla had to do this for people not willing to use "make-archive" + "tag". It saved them quite some time for occasional contributors. But it's quite dangerous to send unrecorded patches. If your patch isn't merged immediately, you'll have great pain resending it and updating it later. Let me tell you my first contact with Darcs. I was contributing a small script for ion3, and had never heard about Darcs before. I read the, say, 5 to 10 lines tutorial on ion's website, and did : $ aptitude install darcs $ darcs get http://location/of/ion3/script/repository <hacked a bit> $ darcs add my-stript.lua $ darcs record -a # it gently asked me a name for the patch $ darcs send # it gently asked me which patch to send. He knew already the patches # that were in upstream, so asked confirmation only for my own # patches. # # then it sent a mail to the maintainer (I didn't even have to provide # the email, Darcs already knew it) No cheating, I really didn't do anything more. bzr isn't yet that "polished", so you have to do the last step partially by hand. > 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. That's an option. Another one is to send ancestor:/the/branch/to/which/you/sumit..last:1 which will send all the patches that the other guy doesn't have. > Perhaps we could share some settings with these hypothetical > routines, however, like mapping branch nickname to email address. branch nicknames are probably not meant for this. At least, that's not how the bzr developers use it. > 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". See above, it's just an alias. -- Matthieu ------------------------------------------------- envoyé via Webmail/IMAG ! _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
