[ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git"

On Fri, Mar 15, 2013 at 10:24 PM, Tore Anderson <tore at 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