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. > 2) The identifier for the base revision it applies to. If you don't > have this, you can do inexact patching with "patch", but you can't > use the more advanced merge operators of the revision control > system. In particular, you can't do 3-way merge and you can't apply > a patch if a file has been renamed in the meantime. Perhaps so. > 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". > 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. 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. > Sending a bundle by email and then applying it should give the same > result as using merge/pull. It is not the case with patches. > >> 1. It would be easier for most upstream authors to read. > > bzr, hg and darcs bundles are as easy to read as patches. Indeed, they > are mostly patches with additional comments. 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. >> 2. Because of (1), patches sent would have a greater chance of being >> accepted. > > patch can read bundles. It will just ignore the comments. Which kind of bundles does this apply to? Definitely not tla. Probably not darcs either, since they use a "special" diff format. Can the patches of one RCS be used by the tools of another? >> 3. When upstream changes version control systems, pending patches >> could follow them more easily. > > Same as above. > >> 4. Mail clients and newsreaders can handle diff files better, since >> they have an associated MIME type already. > > Just use the same MIME type for bundles. > >> 5. It would make the process of writing submit routines for new >> backends significantly easier. > > Not sure about this. In bzr, hg and darcs at least, 95% of the code is > already in the back-ends (well, bzr's submit by email feature is not > completed yet, but there's a Google SoC project on this). Perhaps so. But until that code gets into bzr stable, it won't be available for me. >> 6. Expanding on (5), we could even factor out some common routines >> into dvc-submit.el or dvc-utils.el and add some useful >> abstraction. > > That would be the only benefit IMO. Meh. Commonality is a very *large* benefit, IMHO. 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. -- 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
pgpfMdNpTqVd9.pgp
Description: PGP signature
_______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
