Michael Olson <[EMAIL PROTECTED]> writes: > Matthieu Moy <[EMAIL PROTECTED]> writes: > >>> What other information is really needed in order to rebuild a >>> revision? We already include the log message in the commit email -- I >>> can't think of anything else. >> >> 1) A way for people to apply it easily without Gnus/DVC/... If you >> have a patch with the log message in the body of the mail, the >> recipient needs to apply the patch _and_ cut-and-paste the log >> message. > > 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. >> 3) The revision identifier for the target revision. Without this, you >> can't track history properly, and this will break further merges. >> In particular, you can't easily say whether a patch has already >> been applied or not (you break "bzr missing"). > > I think adding a line near the version information in the email > message that lists the target revision would be sufficient. I don't > really care about the implementation of my patch not showing up in > "bzr missing". But you do care about submitting two related patches, and giving the maintainer a smart way to merge them, do you ? And this is also broken by patches. 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. >> 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. Additionally, occasional contributors may later publish their branch, and after they do, you don't want your first "merge" to be painful. It _will_ if you have exchanged patches in between. > 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 --- foo.txt +++ foo.txt -b +a Then, you merge a 1Mb patch from upstream, to keep up to date with the development. Then you commit a second patch doing --- foo.txt +++ foo.txt -a +c You want to send the change --- foo.txt +++ foo.txt -b +c 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 ... > I wouldn't know about bzr. tla's bundles were awkward to read and > apply since they had a separate diff for each file, rather than one > diff for all of the changes. True (but you had a command to view the changeset as a single patch). Indeed, an equivalent of bundles for tla has been discussed several times, but has never been implemented, so you don't have those "bundles", but you have changesets instead. But I don't want to biaise DVC for tla support. I agree to have a plain patch submission with back-ends which do not have clean bundles, but I see only inconvenients in plain patches over bundles when they are correctly supported. > Which kind of bundles does this apply to? Definitely not tla. See above for tla. > Probably not darcs either, 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. > since they use a "special" diff format. Can the patches of one RCS > be used by the tools of another? Not more that plain patch, no. > Perhaps so. But until that code gets into bzr stable, it won't be > available for me. 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 > Meh. Commonality is a very *large* benefit, IMHO. Then, why use bzr while you already have diff and patch ? > That said, once this new bzr changeset functionality gets to me, I'll > take a look at it. I'm still sold on the idea of using diff for > everything though. -- Matthieu _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
