Hey guys,
I'm sending this email based on an IRC conversation that got a bit
insane, so it seems better to convert it into a huge mail thread
instead. :-)
A few of us at Google were wondering about the status of
merge-tracking stuff, and why the merge-tracking branch hadn't been
merged to trunk yet. I found Dan Rall in IRC and basically asked,
"hey, that branch isn't all disruptive and destabilizing anymore,
right? You're just doing refinements, finishing up the last few
missing pieces of the new feature... so why not just merge it to trunk
already?"
Dan said that he didn't want to merge to trunk yet, because he was
afraid of possibly holding up a 1.5 release.
At that point, a bunch of people came into the channel and all piled
onto the conversation. Most of us were of the opinion that
merge-tracking was the very *definition* of svn 1.5, so of course Dan
shouldn't be worried about merging. I think Erik H. disagreed,
though, saying that there were enough things on the trunk already to
warrant a 1.5 release. (dav-mirroring, ra-dav refactoring, multiple
moves and copies, 'svn changelist', bindings improvements, ...)
Personally, my feeling is that I don't want 1.5 to be another release
that comprises a few medium-sized new features; I think it should
have one big "jaw dropping" feature like merge-tracking, something
that actually makes people excited to upgrade.
There were some other issues that came up, as well:
* Dan Rall pointed out that the feature isn't fully finished yet,
and expressed some insecurity about whether this is the "right
way" to do it. While many of us in the channel agreed that svn
2.0 would solve the problem differently, this was the right way
for 1.x.
* Dan Berlin pointed out that we need to be careful about managing
expectations; when finished, the new feature won't be much more
than a replacement for svnmerge.py.
* A lot of the reason people want the branch merged to trunk was to
give it more attention and testing. Problem is, we can't test the
feature without running trunk code on svn.collab.net (it requires
new RA methods), and as a community we have a long-standing rule
about only running released versions on our own server. So how do
we deal with this? We've *got* to do "eat our own dogfood"
testing before releasing it to the public, not just depend on unit
tests.
So, here are the questions I'm throwing out to the list:
1. Should svn 1.5 block on the completion of merge-tracking?
2. How do we test merge-tracking effectively?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 13 22:35:50 2006