Thanks for the feedback, Antoine!
Antoine Pitrou wrote:
Daniel (ajax) Diniz <ajaksu <at> gmail.com> writes:
Sometimes, non-obvious bits like the right sequence of svnmerge commands, the right way to link a Rietveld code review to a given issue or checking for correct autoconf version might get in the way of real development.
Well, really, rather than trying to improve svnmerge, we should try to find a way forward to switch to Merc... oops, I mean what will turn out to be the best DVCS for our needs :-)
That was a little bait for input ;)
But the real point is that, regardless of underlying VCS, there is a choice between "having all core developers know by heart the right switches and order of steps to correctly checkout/update ->( branch locally) -> fix -> diff -> commit -> merge -> solve conflicts" and "offering a little, well-documented script that takes care of the switches and sequence of steps".
Maybe a 'untangle svnmerge-created history' tool would help too? :)
I am also available to help with the Python workflow part, and there's an early effort to integrate Rietveld and our bug tracker under way.
Food for thought example (sorry, not quite how a core dev works):
SVN exporting current working copy to: ../month_delta
Does it work when using an hg/bzr/git mirror? There's already hg and git support in Rietveld's upload.py, so this should be possible.
Given that the pyfix script is completely imaginary ATM, yes, it works as well with hg/bzr/git/perforce/CVS/darcs as it does with SVN :)
In a more serious note, the PIDA offer puts anyvc on the table. So we could support different VCSs as upload.py does it, or aim for a more pluggable way, probably based on anyvc. Either way, them scripts should be simple and follow the Unix way, so e.g. pyfix --export would actually call anyvc --export or pyvcs --export.