Re: Tracking "branch heads"

Greg Ward wrote:
> On Thu, Dec 17, 2009 at 3:57 AM, Michael Haggerty <[email protected]> wrote:
>>> +
>>> +      branch_heads[(id, name)] = svn_commit.revnum
>>> +
>> Shouldn't this rather be "branch_heads[id] = (svn_commit.revnum, name)"?
>>  I don't see much purpose to requiring both id and name to look up an
>> entry in the map...
> 
> Oh.  Yeah.  Of course.  Good point.
> 
>> For that matter, you could just write "branch_heads[lod] =
>> svn_commit.revnum", since LinesOfDevelopment are hashable.  Then when
>> outputting the results you can add the extra information.
> 
> I was worried about the pickle growing madly out of control, e.g. if a
> LineOfDevelopment references other objects, which reference other
> objects, etc.  Pickling base types is safer in this regard.  Plus
> there's the testability thing: how much sense does a lone
> LineOfDevelopment object make outside of its usual runtime context?  I
> would hope it will work, but did not try it.  Do you think it'll work?
> 
>>> +    # Write the branch_heads dict.
>>> +    file = open(artifact_manager.get_temp_file(config.SVN_BRANCH_HEADS), 'wb')
>>> +    cPickle.dump(branch_heads, file, -1)
>>> +    file.close()
>> Then this could become
>>
>>    cPickle.dump(
>>        [(lod.id, lod.name, revnum) for (lod, revnum) in branch_heads],
>>        file, -1,
>>        )
>>
>> In other words, there is no need to commit to which direction the
>> dictionary should run, because there is no need to store this as a
>> dictionary at all.
> 
> Ahh, yes, good idea.  I think I like it.

I think this part answers your objection above to using an LOD as the
key for the in-memory map, because when the thing is pickled only the
LOD's id is stored.

>>> Of note: I do *not* use branch creation events to update branch_heads.
>>>  I have a patch that adds that, but:
>>>
>>>   * it ensures that CVS branches that never actually had any commits
>>> are present in
>>>     branch_heads... but it's not clear if that is a good thing or a bad thing
>>>   * it complicates matters by recording "split" CVS branches under two distinct
>>>     LOD IDs
>>>
>>> Think about it.  I'll send the second patch if you want, but it feels
>>> wrong to me.
>> The user has a chance to change commitless branches into tags.  If he
>> hasn't, it might be because it is a legitimate branch that has been
>> created but not yet used.
> 
> "The user" in this case being who?  The person who controls
> cvs2svn.options and runs cvs2svn?

Yes.

>> I don't understand your second point.  What do you mean by "split" CVS
>> branch here?
> 
> Branches that are created twice and end up getting two fixup commits
> in the svn/hg/whatever output.  I noticed that when that happens, we
> get two distinct LOD objects (different ID) describing the same CVS
> branch.

The only scenario that I can think of when such a thing *should* happen
is in a multiproject conversion in which two projects have
identically-named symbols.  In such a case the symbols are considered
independent of one another and get distinct Symbol.ids.  (They are also
distinguishable because the Symbol instances have different "project"
members.)

But cvs2{hg,bzr,git}, at least the way that I left them, do not support
multiproject conversions.  So I don't see how a single branch can get
two separate Symbol.ids.  Perhaps this is due to recent code changes?

(Oh, and I guess you could cause one CVS symbol to get multiple
Symbol.ids by using symbol transforms, but only by renaming one of the
incarnations of the symbol.)

It is certainly true that a branch can be created in more than one
commit.  This happens, for example, when the file revisions that have to
be included in the branch never existed contemporaneously and also there
is some other branch involved that creates a cycle in the dependency
graph.  But this should *not* cause the branch to have two different
Symbol.ids.

Michael

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1667&dsMessageId=2433075

To unsubscribe from this discussion, e-mail: [[email protected]].