Julian Foad wrote on Fri, May 01, 2015 at 14:24:06 +0100: > Daniel Shahaf wrote: > > Julian Foad wrote on Thu, Apr 30, 2015 at 10:30:39 +0100: > > > ... > > As an alternative, element ids could be made unique only throughout > > their branch and all branches that are copy-wise-descendants of the > > copy-wise-primogenitor of the branch that contains them — so, for > > example, /subversion/(trunk|branches/*) are one "element id space", but > > but /httpd/httpd/(trunk|branches/*) would be (together) another "element > > id space". > > > > After all, merging from httpd/trunk to subversion/trunk > > isn't defined; letting them have distinct element-id spaces would > > model that undefinedness. (I'm not sure how this compares with > > "branch families", which had been eradicated before I took a close look > > at the branch. Let me know if I just rehashed something that's been > > discussed already.) > > Indeed, that was exactly the "branch families" model. Originally the > segregation seemed to be necessary in order to model subbranches, but > it is no longer necessary for anything. It is not necessary to have > segregated sets of EIDs in order to recognize that 'http' branches > have nothing in common with 'subversion' branches: the lack of any EID > appearing in both is sufficient. > > Non-segregation is useful for certain scenarios such as if the user > decides to combine previously separate branch families into one > family. This is demonstrated in > > svnmover_tests.py 11: restructure repo: projects/ttb to ttb/projects >
Another use-case for global EIDs: moving a file from mod_dav_svn (in svn) to mod_dav (in httpd). > If we want to model segregation of separate projects, this can be done > on top of the single-family model, whereas the reverse would not have > been possible. > I'm convinced :-) > >> Another significant property of a branch in this model is the > >> one-to-one correspondence between the (instances of) elements in this > >> branch and those in another branch, for the elements that appear in > >> both of the branches. > > > > I'm not sure I understand. Are you saying that element ids allow us to > > easily answer the question "What has element X on this branch been > > renamed to on that branch"? If so, then yes, it does, but how does it > > handles bifurcations [...]? > > Bifurcation (splitting and joining) is deliberately not handled > specially -- only in the same way that it is now, by the user choosing > at most one 'tine' of the 'fork' to be the successor and the other(s) > to be plain copies. I decided modelling bifurcation explicitly at this > level would be too complex to justify for the relatively rare cases > where it could be useful. > > The first level of complexity is reached as soon as you realize that > 'splitting' is not a one-to-two relationship but a many-to-many > relationship (because you might split the same thing on two different > branches) and thus leads to a concept of groups of related elements, > and you have to choose what kind of relationship they should have -- > perhaps a flat 'set' relationship, or a hierarchical relationship like > the tree formed by the existing 'copying' relationship. And then > justify why should it be different from what the 'copying' > relationship gives us. > > In fact, the 'copy' relationship might be the *right* way to represent > splitting. Bear in mind that 'copying' will no longer be needed for > branching or merging-an-add or resurrection, as all of these are > handled explicitly by the new model. > Sure, there is no need to invent two kinds of copy operations, one for bifurcations and one for everything else. I think the main question is: should the data model support efficiently the operations that a "merge through copies" functionality¹ would require? That functionality itself (up in libsvn_client) needn't be implemented right now, but we may want to design the data model with an eye towards possibly implementing that functionality in the future. Basically, while we're inventing a new data model anyway, would it be feasible to make it support cheap computation of copyto? So the mv-t-2 branch introduces a data model that supports move tracking (via EIDs) and cheap copyto computation, and implements move-aware merge tracking on top of that data model, but doesn't implement any features on top of the cheaply-available copyto information. ¹ To be explicit, the use-case I have in mind is: change a file on trunk, split it on branch, merge the trunk mod to branch, have the change propagate to both copies on branch of the file. > > and I don't see what use-case it serves > > other than users who accidentally created their contents in ^/ rather > > than in ^/trunk. > > That's an intentionally served use case. The suggestion of requiring > people to have designated /trunk as a branch *before* creating any > contents in it was considered very bad for compatibility with > historical usage. This model has no such restriction. > That's not quite what I said, but as you said, it's a UI concern. The parts I snipped I agree with. Thanks for the answers and output snippets. Daniel
