tinycc-devel
[Top][All Lists]
Advanced

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

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


From: KHMan
Subject: Re: [Tinycc-devel] Sample patch from Mercurial repository
Date: Fri, 02 Nov 2007 20:37:30 +0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4

grischka wrote:
> From: "KHMan":
>> I will push patches to grischka, and check every few patches with
>> Ubuntu "make all", and the two trees should come together. 
> 
> Do you think it is possible and/or makes sense to extract all 
> changesets from Rob's repo into single patches first, with an 
> automatic script or something?

That's easy to do with hg's export. I am using something like:

  hg export 395

Appears to work. I'll write a perl script to do the job.

> Then we could give names to the patches, put them into some 
> order, group them in sub-directories etc. 

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. I am doing this
on cygwin and using WinMerge for visual diff where necessary.

This weekend I will make some time for it.

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. I'll send you a
tarball of both, a bunch at a time.

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'm not really sure about the details part, because I can't really
do any quality assurance or assessment of the patches. I was
thinking, just pump them into the CVS, never mind the details, and
the Mercurial bundle can be the starting point of new development.
After all, I agree that next-generation version control is much
more flexible than plain old CVS. The list only need to agree to
keep pumping patches into the CVS, in order to keep tcc in
"virtually one piece".

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia




reply via email to

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