On Fri, Mar 15, 2013 at 10:24 PM, Tore Anderson <tore@fud.no> wrote:
I can see one particular advantage of using a version control system - the "git blame" command, which will show when a particular sentence or paragraph was added or last modified. There's several times I've read RIPE documents and wondered along the lines of: «Where did this come from? What was the rationale behind it?» I rarely go through the trouble to find out.
For example: Re-allocated blocks will be signed to establish the current allocation owner. ;)
That said, while I agree that Git is a very good tool, I'm reluctant to micro-manage the NCC by saying «you MUST use Git» (or any other particular tool for that matter).
I am painfully aware of that. The community is free to shoot this down, but if it's accepted, it would be possible to change this. _Especially_ once there's a yearly list of services through which RIPE NCC can give feedback on if they want to get rid of it and replace it with VCS 3.0 in a decade.
The current system can be improved a whole lot without requiring a version control system, I like to point to the IETF's tools page, which shows all the revisions of a draft leading up to its publication as RFC, and where you can generate both in-line and side-by-side diffs on the fly. One example:
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-09
Submitting Internet Drafts is a different valley of pain, but the end user interface is somewhat decent. Still, RIPE NCC would need to either ask for that code of code a similar system themselves. Gitweb and gitolite are free and available today. Plus, IETF lacks any offline capabilities.
In any case, for maximum use of any form of version control system, you'd have to consider that even though e.g. ripe-582 is a new version of ripe-577 which in turn is a new version of ripe-553 and so on, the history of ripe-582 alone isn't nearly as interesting as the history of ripe-582 plus all preceding versions combined.
Internally git tracks changesets, not files. Thus, there is no `git cp` which allows you to trace the forking of a file directly. That being said, git log supports --find-copies which does the same on the fly. Also, just like RFCs, documents carry inline information about what other forms they update.
So either the file name needs to stay the same between versions (unlike today). or you'd have to import the entire history of the previous version into whatever you're starting the PDP with for the proposed new version. I don't know if Git allows for this.
If you have an existing repository, importing the old data into the past of the repo will change history, resulting in issues for everyone who cloned from that repo. There are two ways to mitigate this: 1) Recreate full history before starting to really use the main repo. Optionally have a scratch repo for new PDPs which can be rebased on top of the historic repo once it's done. This leaves you with a sparkling clean history, but is a lot of work up front and means people need to actively migrate away from the temporary repo. 2) Use main repo without full history from day one. Once history has been recreated, merge current master into the history and make that the new master. You would have one clear spot in your history where you would always be able to see that two repos were merged. But the actual impact is neglible and work up front minimal. Richard