On 08/03/07, Alan Conway <[EMAIL PROTECTED]> wrote:
Martin Ritchie wrote:
> I have been using this on the perftesting_persistent branch and it
> greatly simplifies merging. If you are wanting to use for the M2
> branch merging the different languages I would recommend doing the
> init at the language level. This would allow you to merge each
> individual language as required but retaining the power of svnmerge
> telling you what revisions are available for merging.
I've been playing around and I don't think init on the subdirs is the
right way to go. Some changesets span across projects, and we don't want
to lose sight of that. E.g. the recent change to amqp.0-8.xml is
associated with changes to the Java codebase and merging one without
considering the other might be a bad idea.
svnmerge isn't as simple as I'd hoped but I think it is still useful,
even if we end up doing much of it manually. At least svnmerge will
reliably give us a list of oustanding merges to consider, and a reliable
way to record what we merged (with svnmerge or manually) or blocked as
not-to-merge. That will be a lot more effective than a shower of emails
full of cut-and-paste revision numbers and log messages.
Indeed. Tell me about it. I was using 'svn merge' (not the
svnmerge.py) on a previous branch and it was ok to start with but when
you want to exclude something it became very difficult ot keep track
of what had been, hadn't been and shouldn't be merged.
svnmerge is a small step in the right direction but svn is just not
very good at this sort of thing.
--
Martin Ritchie
