Re: Tracking "branch heads"

Greg Ward wrote:
> for converting from CVS to Mercurial (and probably other DVCSes), it
> would be nice for the OutputOption to know when it is processing the
> last revision on a particular branch.  Eg. for Mercurial output, one
> could choose to mark that branch 'closed' or dummy-merge it into
> another branch.  I believe that would be useful for Git and Bazaar
> output as well.
> 
> I've peeked at the code, and it looks like the dumb way to do this is
> to add code to my custom OutputOption that duplicates the loop over
> all svn revisions in OutputPass.run().  That's fine if you're
> converting 1000 revisions in 5 minutes, but I'm converting 104,000
> revisions and it takes ~14 hours.  (Yeah, there is a performance
> problem there.  Not sure if it's my code or Mercurial or just the
> plain fact that there are a lot more files in our rev 104000 than in
> rev 1000 or rev 20000.)

That is not attractive.  One would also have to make sure that revisions
are created in the exact same order in the two iterations, which
*should* be the case but I wouldn't swear that there is no arbitrary
ordering decision hidden somewhere in the code, or that one won't creep
in sometime in the future.

> So it looks like the clever thing to do is modify CreateRevsPass to
> build a dictionary mapping branch name to highest rev number on that
> branch, then ensure that dictionary is persisted somehow and available
> to OutputPass/OutputOption.

Sounds reasonable.

By the way, another elegant way to solve the problem would be to add one
"CVSBranchTip" CVSItem into the dependency graph for each branch.  Such
an item would depend on the last commit on the branch in each file.  The
normal dependency-sorting code would make the corresponding "commits"
occur after the last commit on the branch, and the OutputOptions would
see them come through like any other commit.

These "events" would also be significant if somebody ever decides to
implement incremental conversions.  The BranchTip "commits" would be
markers indicating the boundary between conversion N and conversion N+1.

> Questions:
> 
> 1) any interest in such a patch being accepted upstream?  I'm pretty
> sure it will be orthogonal to my "add cvs2hg" patch series, so I could
> send it in as soon as it works, if you're interested.

I don't see a problem with it.

> 2) terminology: in Mercurial, we would call this "a branch head" (or
> "the branch head" when dealing with CVS/svn data).  AFAIK, CVS has no
> standard terminology.  What does Subversion call "the highest-numbered
> rev on branch X"?  What should cvs2svn call it internally?

I don't think that SVN has this concept.  "HEAD" is similar, but it
refers to the highest SVN revision number for all branches, not for a
particular branch.  I suppose "branch head" or "branch tip" would be
understandable enough across VCSs.

> 3) how should I persist the dict?  it'll be small enough to just write
> a pickle in the tmp dir: is that acceptable?

Yes (to the cvs2svn tmp dir, of course, not /tmp).  IIRC these are the
places that you should adjust:

* Add a constant for the filename in config.py and a short comment
telling what it is for.

* Tell the ArtifactManager which pass creates the file and which
pass(es) read it.

* Document it in doc/design-notes.txt under the pass that creates it.

> 4) how should I make it available to OutputPass/OutputOption: just
> make the filename a constant somewhere and let the OutputOption author
> figure it out?

Either let the OutputOption read the file itself (based on the filename
that it knows from config.py), or you can stick it in our strange
collection of global variables stored in Context with a name that starts
with an underscore.  (The naming convention means that the Context
member is not persisted from pass to pass.)

Michael

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

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