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

Subject: Re: [boost] Git Modularization Review no vote heads-up
From: Daniel James (daniel_at_[hidden])
Date: 2013-05-31 11:27:22

On 30 May 2013 23:27, Dave Abrahams <dave_at_[hidden]> wrote:
>
> on Thu May 23 2013, Daniel James <daniel-AT-calamity.org.uk> wrote:
>
>> On 23 May 2013 14:47, Dave Abrahams <dave_at_[hidden]> 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.