On Saturday 03 January 2009 17:36:04 Martin v. Löwis wrote:
As far as your goal is concerned, couldn't you live with a branch where you develop the feature?
That still doesn't help the change getting merged into the trunk. Whether you store it in a patch file, in a DVCS, or in the very same VCS-but-different-branch - these are all minor details, which may affect the efficiency of producing and technically integrating the patch. It doesn't help to the least in speeding up reviews of the patch, or reduces the amount of work necessary to do a review.
This is true...
Actually, I'd like such a branch, too, where I could move much quicker and in particular with the backing of a VCS to port Python to MS Windows CE. Currently, I'm tempted to pull the code into a private repository, which causes problems when I want to push it back upstream.
[I guess you aren't happy with the DVCS systems, such as bazaar, which supposedly work perfect in exactly this case. I won't blame you for that, but still, consider trying out one of them for this project]
I tried bazaar, but it's just too much to tackle at once: porting to CE, learning BZR and maintaining a feature branch on trunk (though the latter should not be too difficult, according to BZR's reputation).
We can setup such a branch, unless you reconsider and try bazaar first. There wouldn't be any pushing it back upstream, though - you would still need to go through the tracker for all changes. The only advantage I can see is that it simplifies repeated merging of the trunk into your branch.
Actually, now that I think about it, I must admit that it doesn't really matter to me whether I use a local mirror or work on a remote branch. The problem is still splitting up the whole port into pieces that can be digested (read: reviewed) at a time. Since I'm confident with the use of SVN, I'll for now stay with it and a local mirror, but any single change that can be submitted will be submitted, hopefully to have something working here soon.