I've a few things on my mind to do with what the new merge tracking is
bringing. First, can I check where we are with managing people's expectations?
V1.5 merge tracking brings a lot of good stuff. We are well aware that it
doesn't magically solve all merging needs, and that's fine.
People upgrading to from Subversion 1.4 or earlier are going to be very happy
if they use the improvements incrementally.
People switching to Subversion or starting to use merging in a big way need to
be told clearly what the capabilities and limitations are, lest we disappoint
them and give ourselves a bad name just because they assumed we were providing
an ultimate automatic solution to all their merging needs.
WHAT I WANT TO AVOID
In my day job we sometimes have trouble with merging in Perforce. In simple up
to moderately convoluted situations it does what we expect, but among some
branches we've built up some (over-)complex merge history and there it
repeatedly re-merges files that haven't changed or fails to merge files that we
think it should, and users get angry with it. Why? We must have made changes
that don't fit the conceptual model and limitations of its merge tracking,
because we just had the impression that it tracks all changes and magically
Does The Right Thing. We'd probably not be in this situation if we had a clear
understanding of The Rules for using it in ways that work well.
The same will happen to Subversion users. Let's try hard to minimise the amount
this happens.
1. STATEMENT OF SCOPE
We've said before we need to state the capabilities and limitations in the
public introductions to v1.5 merge tracking (web pages, release notes, book).
Just a couple of sentences summarising what kinds of merging will work well
and, importantly, what kinds will not, and a link to more detail.
* What/where is the best "statement of scope" we have written down right now?
* Has anyone got this on their "to do" list?
<http://subversion.tigris.org/merge-tracking/> seems a good place but what's
said there right now needs tightening up a lot.
2. FEATURE NAMING
* Should we call the feature some phrase like "basic merge tracking" now so
as to be sure not to imply "all you could possibly want from merge tracking"?
It would be a shame to have to use a phrase like "merge tracking plus" or
"Really, fully, honestly complete merge tracking" to describe what we provide
later in v1.7 or wherever. But maybe there's no need to under-sell it thus, as
long as we're careful to explain it.
3. FUNCTIONAL SPEC
We need to be able to refer users to a functional (semantic) spec that is
approachable by non-experts who want to understand the capabilities and
limitations. This could correspond to the first part of a chapter or a
reference section on merging in the v1.5 book.
I can provide some notes on what I'd like it to cover. Some of it is simple but
there are complexities that matter like whether "resolve by accepting the
source" copies the text of the source file or copies the file object -
differences that it's all too easy for the user interface to hide away completely.
To be honest, I have a concern that until we write this we won't really be
aware of some of these complexities ourselves.
* Is anyone working on or intending to work on such a spec?
A useful start would be to update
<http://subversion.tigris.org/merge-tracking/func-spec.html> and move all
mentions of "svn:mergeinfo" out of it and into the design spec. Other sources
of info are <http://subversion.tigris.org/merge-tracking/requirements.html>
from which we need to identify which use cases are supported and which not, and
<http://www.orcaware.com/svn/wiki/Svnmerge.py>.
Best way forward on these three point in particular, anyone?
Regards,
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 17 17:50:16 2007