Bert Huijben wrote: > On the Berlin hackathon the suggestion was raised that it might help that we > standardize a new 'svn:branch' property to give tooling a hint on what > directories are branches and which aren't. [...] > > Client tools like TortoiseSVN, Subclipse, AnkhSVN could really use some > standardized hint to suggest better defaults to the user. > > * Merge and branch tools can automatically suggest which directory to merge
I wasn't going to respond to this thread but I got sucked in :-) I think the idea of simply tagging certain nodes in certain revisions as "this is a branch root" is ridiculously weak. I agree it would *work* to the extent of being able to implement some simple UI hints such as "You want to merge 'update-editor.c' but it isn't marked as a branch root, but 'trunk' is, so merge at that level instead?" But it seems so hacky and limited. Limited for example in that I would want to be able to ask not only "is this a branch root" (or "where are the branch roots between this path and ^/"), but also "where will I find the other branches of this (project|branched-thing)?" Maybe the other branches of *this* (project|branched-thing) are mixed up with branches of other (projects|branched-things). Hacky in that I have seen hardly any semantics mentioned. What does it mean to say that a node is a "branch root"? Does it mean "somebody has done a merge to or from this node in the past"? "Somebody thinks they might want to merge to or from this node in the future"? "This node shares a common copy-from ancestor with one or more (unspecified) other nodes in the repository"? If more and more people keep doing merges over time, sometimes using the "wrong" root (on purpose or by accident), and sometimes press the "Please mark this as a branch root for future use" button, then over time you'll find that "update-editor.c", "libsvn_wc", "subversion" and "trunk" all have that property set. Then where are we? [Bert responded: "Same as where we are right now."] If we can set this property on an already-existing trunk or branch, then what about old versions -- does it not matter to anybody that the old versions are not marked? It would matter to me if I were writing a client that includes any kind of history browsing. On IRC just now [1], Bert talked about storage and transmission of "this is a branch root" data, arguing that a versioned prop is good because the client can see the value immediately and that the 'enversion'[2] way, which is using revprops, is not good because of the difficulty of reliably caching revprops on the client for fast look-up. To me, those are valid implementation concerns but almost orthogonal to the design issue of what semantics we should be providing. Bert said, "Then just lets see if we can get better than the current 'we don't know if there is a root'. Currently Subclipse has 'subclipse:tags' property, AnkhSVN has 'vsroject-root' [...]. I suppose the other way to respond is that this idea doesn't seem suitable as a core piece of Subversion design, but it doesn't need to be: it's a client-specific feature. You can certainly define a common name for a branch-root boolean property, to be shared by several svn clients. Talk to those other clients' teams and choose a name. The name should not start with "svn:". I know it would be nice and convenient if it was defined centrally here, but ... I dunno, others may disagree, but I think we need a much more rigorous definition before I'd be happy to consider it. - Julian [1] IRC conversation starting at <http://colabti.org/irclogger/irclogger_log/svn-dev?date=2012-07-17#l106>. -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
