On 2008-08-19, Stefan Sperling wrote (in private, with permission to go
public):
(In response to me saying I'm tasked with getting some basic
tree-conflicts stuff working ASAP but am wondering how to proceed to a
more solid designfrom there.)
> Regarding the short term, I think we should accept the fact that the
> tree-conflicts branch as-is cannot be perfect. We know a lot
> more about the problem now than when we started working on it.
> Holding the branch up to today's standard of our understanding of
> the issue is not a good idea, that's just mocking the branch.
>
> Now, I think one big reason I had concerns about Greg's work
> "interfering" with ours is that we have been on the branch
> way too long. I think (like you do) that we should merge the
> branch to trunk ASAP (possibly in small incremental steps if
> that helps). I now think that this is a better solution than
> starting from scratch. We can take an evolutionary approach.
>
> A possible plan for this, as far as I can see, would be to ...
>
> 1) ... feature-freeze the branch *now*.
> Forget about adding directory support while still on the branch,
> it is simply taking too long. Make it clear that the current
> focus is on files. The current feature set is what we can
> realistically expect to get fully working by 1.6 release.
I hate to say I *can't* do directories, but I haven't been able to do it
yet. I am getting closer, but keep finding complications and side issues
getting in the way. So, yes, I agree this is probably a sensible thing
to do. Doing this cannot hurt the attempt to get directories fully
supported as well.
> 2) ... focus on the user experience instead.
> The branch has UI issues. At least I'd like users to be able
> to mark individual victims as resolved (issues #3144 and #3145).
> Also, printing a conflict summary after update/merge, which contains
> the same information as the 'svn info' command provides would
> probably improve the user experience a bit (new idea, no issue
> for that).
>
> I think the UI issues are more important for the acceptance
> into trunk than 100% tree conflict detection.
You might be right.
> Once the branch is merged, we can continue our work on tree-conflicts
> on trunk, in concert with gstein's work. There are many exciting ideas
> floating around that we can't implement on the branch anyway,
> e.g. automatic resolution of some cases via better rename tracking,
> configurable tree conflict resolution policies during merge/update
> which override built-in defaults (Nico's team have done some ground
> work for that, BTW, to be released before Subconf, hint hint), the
> goal of detecting virtually every tree conflict, just to name a few :)
>
> Julian, I don't know what your current plans are with the branch,
> do they go in a similar direction or do you have a different approach?
> What's your plan? Do you think it's realistic to go for a merge
> into trunk with the current state + issues #3144 and #3145 fixed?
That is the direction I'm going in. I've started doing
tree-conflict-detection stuff on trunk because there's too much changed
on the branch for me to be able to remember what it all is and it's
getting stale. I'm trying to review it right now to bring the useful
parts of it into the trunk.
> Unfortunately I won't be able to participate actively until maybe
> in a few weeks. :(
It would be great to have your help then, and I see that Neels who may
have been a colleague of yours is starting to help now too, which is
just what I need.
Regards,
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-19 18:00:31 CEST