[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Sample patch from Mercurial repository

From: grischka
Subject: Re: [Tinycc-devel] Sample patch from Mercurial repository
Date: Fri, 2 Nov 2007 14:39:30 +0100

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 

    patch: 395.diff
    shortname: <empty for now>
    description: <changelog entry here>
    link: <link into tinycc mail archive, if available>

    patch: 396.diff
    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. 


--- grischka

reply via email to

[Prev in Thread] Current Thread [Next in Thread]