From: "KHMan": > However I think some of David Dodge's patches have already been > applied, and bits of documentation has been updated in CVS, so I > guess that some hg patches will not apply cleanly.
Yes, might happen, but we can deal with technical questions later. > I am doing this > on cygwin and using WinMerge for visual diff where necessary. Yes, WinMerge is good, using it myself. > As for changesets, my plan is to name them using the revision > numbers, like "cvs395.diff". I will keep a set of hg exports, like > "hg395.diff". This is to preserve commit order. Hm, I don't understand exactly. Why do we need two sets of files? Well, just had another idea. Instead of renaming the patches we could use a meta-text-file with descriptions and references like: patch: 395.diff shortname: <empty for now> description: <changelog entry here> link: <link into tinycc mail archive, if available> patch: 396.diff shortname: description: ... link: ... .... Then we would just edit that meta-file, move entries around etc, and, if useful, eventually with another script build a patch-file tree from that meta-file. Do you think your coming perl script could generate such meta-file along with the diffs? :-) > I see a lot of work on files like tcc.c, so I assume changesets > need to be applied in order (as the lowest common denominator), > moreso with what appears to be some refactoring work done by Rob. > So, well, perhaps they can be named like > "cvs395_Does_foo_bar.diff" or something like that. Can the > changesets be mixed about and later applied in non-chronological > order? I'm not sure about this, so I am doing this conservatively. I don't think the order will be a big problem. The patch program has some options, and if nothing works then we would just patch it manually. Also, tcc.c looks more different than it actually is due to some mere formal changes. > I'm not really sure about the details part, because I can't really > do any quality assurance or assessment of the patches. Yes, that's what I mean our own order is for. First priority to undoubtful and neccessary patches, bug fixes etc. Then feature extensions and everything else to make as many people happy to see in tcc-0.9.24 as possible. The rest put back after the release, that would be in my opinion mere formal changes, untested patches and side-features that cause to much changes for the benefit. > The list only need to agree to keep pumping patches into the CVS, > in order to keep tcc in "virtually one piece". Well, I think we can and should present the edited meta-file to the list and have some discussion. Also we might still find other patches that Rob doesn't have yet. If we want to step towards distributed development then it is useful to do things in public. Cheers, --- grischka _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel