librelist archives

« back to archive

cliques in merge_branches?

cliques in merge_branches?

From:
Tom Enterline
Date:
2014-12-12 @ 04:41
Hi,

I've been looking at merge_branches and git_commit_build, and have some
questions.

From the comments, I would expect each CVS commit to end up in clique,
and one git commit, but that's not what I'm seeing. It seems that the same
CVS
commit (as identified by date and commit ID) can end up in several git
commits.

I thought that might be an artifact of how the test case repos are
generated,
where the make rebuild generates the repos. To test that, I reduced the
commit_time_window from the default 300 down to 2, but that didn't help.

More generally, I still don't really understand the clique generation
process.
I can see that skip indicates the start of the clique, but where does it
end?
The whole revisions array is passed to git_commit_build, which then puts
all
the non-dead revisions into a commit.

I was looking at git_commit_build, since I noticed that checking for
non-dead
CVS commits was a hot spot.

Re: [cvsfastexport] cliques in merge_branches?

From:
Eric S. Raymond
Date:
2014-12-12 @ 04:50
Tom Enterline <tenterline@gmail.com>:
> I've been looking at merge_branches and git_commit_build, and have some
> questions.

I wish I had answers...
 
> >From the comments, I would expect each CVS commit to end up in clique,
> and one git commit, but that's not what I'm seeing. It seems that the same
> CVS
> commit (as identified by date and commit ID) can end up in several git
> commits.

That's bizarre.  Have you demonstrated this on a test repo?

> More generally, I still don't really understand the clique generation
> process.

You have lots of company. Nobody else does either :-(  I've been able 
to modiy it only by making small local changes and regression-testing the
hell out of them.

If you can figure out anything about this that isn't already in the
comments, *document it*.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [cvsfastexport] cliques in merge_branches?

From:
Loz
Date:
2014-12-12 @ 09:46
On 12/12/2014 04:50, Eric S. Raymond wrote:
> Tom Enterline <tenterline@gmail.com>:
>> I've been looking at merge_branches and git_commit_build, and have some
>> questions.
> I wish I had answers...
>   
>> >From the comments, I would expect each CVS commit to end up in clique,
>> and one git commit, but that's not what I'm seeing. It seems that the same
>> CVS
>> commit (as identified by date and commit ID) can end up in several git
>> commits.
> That's bizarre.  Have you demonstrated this on a test repo?
>
>> More generally, I still don't really understand the clique generation
>> process.
> You have lots of company. Nobody else does either :-(  I've been able
> to modiy it only by making small local changes and regression-testing the
> hell out of them.
>
> If you can figure out anything about this that isn't already in the
> comments, *document it*.
Apologies for the double send, not used a mailing list for a while...

The merge_branches loop takes a complete repo state and peels off a 
clique to give another complete repo state. Each CVS commit ends up in 
one clique, however a git commit doesn't point to cliques, it points to 
complete repo states.

The export_commits function is the bit that turns things into changesets.

You could imagine an alternate scheme where you turn cliques into 
changesets directly. However, it would make some other things more 
difficult. Graph generation would have to change, and the experimental 
mechanism for generating tags asks the question "have I seen this repo 
state before".

Loz

Re: [cvsfastexport] cliques in merge_branches?

From:
Tom Enterline
Date:
2014-12-13 @ 03:29
could not decode message

Re: [cvsfastexport] cliques in merge_branches?

From:
Loz
Date:
2014-12-13 @ 10:40
README has changed between these two commits. The date is different, the 
commitid is different. It was the leader for the first commit.

The first git commit will have the latest cvs commit for each master (on 
the git branch we're merging). But after each commit the revisions array 
is changed, so that we peel off the latest clique of cvs commits.

rev doesn't mean much, it's just an array index. If you want to see a 
revision number you need to call stringify_revision with cvs_commit->number.

On 13/12/2014 03:29, Tom Enterline wrote:
> Relating a git commit to the repo state is helpful.
>
> My testing is with the branchy test repo, I added some printf's to 
> merge.c.
> Here is an example of what I mentioned, the full log is attached.
> The first line of each commit has information from the "leader", 
> followed by the revisions.
> It looks like each git commit includes the latest cvs commit for each 
> master.
>
> git_commit_build nrev 4 skip 0 min 0 max 3 date 1037071693 commitid 
> 1005462D3CD0FA281F3
> git_commit_build: adding rev 0 date 1037071675 commitid 
> 1005462D3BB0F876090 master .cvsignore
> git_commit_build: adding rev 1 date 1037071693 commitid 
> 1005462D3CD0FA281F3 master README
> git_commit_build: adding rev 3 date 1037071686 commitid 
> 1005462D3C60F94DB62 master superfluous
> cvs_commit_time_close diff 7 window 2
>
> git_commit_build nrev 4 skip 0 min 0 max 3 date 1037071686 commitid 
> 1005462D3C60F94DB62
> git_commit_build: adding rev 0 date 1037071675 commitid 
> 1005462D3BB0F876090 master .cvsignore
> git_commit_build: adding rev 1 date 1037071683 commitid 
> 1005462D3C30F9059DE master README
> git_commit_build: adding rev 3 date 1037071686 commitid 
> 1005462D3C60F94DB62 master superfluous
>
>
> On Fri, Dec 12, 2014 at 4:46 AM, Loz <loz@flower.powernet.co.uk 
> <mailto:loz@flower.powernet.co.uk>> wrote:
>
>

Re: [cvsfastexport] cliques in merge_branches?

From:
Tom Enterline
Date:
2014-12-18 @ 04:02
After further investigation, I see that the duplicate CVS commits (e.g.
.cvsignore, superfluous) get dropped in the export_commit commit/parent
merge join.

On Sat, Dec 13, 2014 at 5:40 AM, Loz <loz@flower.powernet.co.uk> wrote:
>
>  README has changed between these two commits. The date is different, the
> commitid is different. It was the leader for the first commit.
>
> The first git commit will have the latest cvs commit for each master (on
> the git branch we're merging). But after each commit the revisions array is
> changed, so that we peel off the latest clique of cvs commits.
>
> rev doesn't mean much, it's just an array index. If you want to see a
> revision number you need to call stringify_revision with cvs_commit->number.
>
> On 13/12/2014 03:29, Tom Enterline wrote:
>
> Relating a git commit to the repo state is helpful.
>
>  My testing is with the branchy test repo, I added some printf's to
> merge.c.
> Here is an example of what I mentioned, the full log is attached.
> The first line of each commit has information from the "leader", followed
> by the revisions.
> It looks like each git commit includes the latest cvs commit for each
> master.
>
>  git_commit_build nrev 4 skip 0 min 0 max 3 date 1037071693 commitid
> 1005462D3CD0FA281F3
> git_commit_build: adding rev 0 date 1037071675 commitid
> 1005462D3BB0F876090 master .cvsignore
> git_commit_build: adding rev 1 date 1037071693 commitid
> 1005462D3CD0FA281F3 master README
> git_commit_build: adding rev 3 date 1037071686 commitid
> 1005462D3C60F94DB62 master superfluous
> cvs_commit_time_close diff 7 window 2
>
>  git_commit_build nrev 4 skip 0 min 0 max 3 date 1037071686 commitid
> 1005462D3C60F94DB62
> git_commit_build: adding rev 0 date 1037071675 commitid
> 1005462D3BB0F876090 master .cvsignore
> git_commit_build: adding rev 1 date 1037071683 commitid
> 1005462D3C30F9059DE master README
> git_commit_build: adding rev 3 date 1037071686 commitid
> 1005462D3C60F94DB62 master superfluous
>
>
> On Fri, Dec 12, 2014 at 4:46 AM, Loz <loz@flower.powernet.co.uk> wrote:
>>
>>
>>
>