Re: [boost] Git Modularization Review no vote heads-up

On 30 May 2013 23:27, Dave Abrahams wrote:

on Thu May 23 2013, Daniel James wrote:

...

On 23 May 2013 14:47, Dave Abrahams wrote:

...

If that were going to be acceptable to the community, presumably everyone would have been happy with the original plan to graft an accurate SVN history when people want to refer to it, no? Please don't tell me that the last several months of work were wasted!

What's acceptable to one person is quite different to what's acceptable to another.

No kidding!

So saying that it would be acceptable for one module, is not the same as saying that it would be acceptable to the community.

...

It should ultimately be up to the maintainers of individual modules.

If anyone expects the Boost master repository to contain accurate submodule references through history, maintainers must not be allowed to delete old branches or rewrite old history.

But the old branches would remain untouched in the historical repo. Before the switch to the new layout, the master module would use that for the submodule, aftewards it would use the working repo. Rather than storing the historical record in a separate repo, it could be stored in separate branches, if that's preferred. And I'm not suggesting that every repository has such a split. Btw. I think people will want to delete branches that aren't relevant to their modules. It might be a good idea to tag them (say, 'svn-branch-name') so that the actual branches can be safely deleted.

...

Also, you would still have an accurate history in the historical module(s). Which was the point, it was an attempt at a compromise between two conflicting desires (to have an accurate history, and to have a repository with a different directory layout).

As I've said before, Git *cannot* represent exactly what SVN represents. If you want an accurate history, use SVN to get it. The best we can do with Git is to approximate actual history.

When I said 'accurate', I didn't mean exact. Just good enough that an historical checkout would look equivalent to the corresponding checkout from subversion.