Note the author is talking about SVN and not git. I haven't used SVN nearly as much as I have git but from what I understand git is likely better suited for combining many different change-sets into many combinations efficiently (according to Git's Wikipedia page it was designed with "non-linearity" in mind), which would seem to mitigate the some of the issues around merge conflicts the OP brings up with respect to SVN.

I was referring to SVN because when I started working in this field SVN was the up-and-coming SCM. You can s/SVN/git/g and still get the same result.

Versioning the text of the law is not a problem. It is a solved problem. Every decent legal office has access to a versioned text of the law. The new challenge is the versioning of the legal content (or _meaning_ if you want) and the (semi-) automatic creation of consolidated texts at a certain point in time. The last point is difficult because the consolidated version is not a single document but a set of possible documents.

See also the other answer I gave on the difference between text and content: http://news.ycombinator.com/item?id=4023109

I see, your post of 'meaning' vs 'text' makes the issue(s) a lot clearer - thanks. What other meaning conflicts might arise other than time-related ones? I think with some clever tagging combined with a script on top of git one could have something tell you "show me what law as it is applicable today - not everything that's been passed for the future"

Cherry picking commits and branching on every possible merge conflict (and picking one winner for each branch) should be relatively straightforward, I guess the question is how big of a set of possible documents might this be - 10? 100? 1000? Would this be a process done by lawyers for the purposes of understanding laws on the books or by someone in the legislature at the end of each session?

Apologies if I'm ignorant on this stuff - I'm just really interested.

> Cherry picking commits and branching on every possible merge conflict (and picking one winner for each branch) should be relatively straightforward

The problem is that, in general, (1) it is not straightforward and (2) you can be liable for damages if you state publicly "this is the correct version" unless you are a judge or the appointed authority.

Talking more practically, here is something that would be interesting to have: a tool that (1) analyses an act (or a bill), (2) identifies which parts of it state a modification to existing acts and codes, (3) have a look at these target documents and (4) tell you which of the "hunks" of the "patch" can be "merged" in a straightforward manner, almost straightforward or require an expert review. Steps 1, 2 and partially 3 are already done in many systems through NLP techniques (have a look at http://wyner.info/LanguageLogicLawSoftware/ for example). Step 4 is a brand new thing. Do anybody want to work on that?

A tool like the last one would simplify things a lot. You go from "sorry, I cannot tell you anything because a lawyer is required for everything" to "here is what I am reasonably sure about; for the last 5% you have to ask your lawyer if the correct merge is A or B".

> I guess the question is how big of a set of possible documents might this be - 10? 100? 1000?

The set of possible versions grows exponentially :(.

> Would this be a process done by lawyers for the purposes of understanding laws on the books or by someone in the legislature at the end of each session?

Lawyers are required. Many institutions publish "end of the year" consolidated versions of their acts. In some countries these consolidated versions have legal power, in others they are just handy references (the judges cannot use them).

Fun fact: it happens quite often that one branch of a parliament thinks that the current version of an act says X while the other branch thinks that it says Y.