Michael Olson <[EMAIL PROTECTED]> writes: > Matthieu Moy <[EMAIL PROTECTED]> writes: > >> Don't use diff. bzr supports "bundles" (in bzr.dev only), which is >> mostly a patch plus some annotation, which is sufficient for bzr to >> rebuild the revision completely on the other side. >> >> DVC can help to use the bzr features here, but should not reimplement >> its own. > > 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. 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. 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"). 4) What patch do you send if your current branch contains merges from upstream, which themselves have not yet be merged ? 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. > 2. Because of (1), patches sent would have a greater chance of being > accepted. patch can read bundles. It will just ignore the comments. > 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). > 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. (Hmm, all that being said, I don't want to discourrage you from contributing to DVC ;-) ) -- Matthieu _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
