[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: RE: More fs fun: COPY sources and detecting LinesOfDevelopment (branches)

From: Bill Tutt <rassilon_at_lyra.org>
Date: 2002-03-15 01:57:41 CET

> From: Bill Tutt [mailto:billtut@microsoft.com]
> > From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> >
> > Okay, Bill, I *think* I understand what you're saying, but let me
> > to summarize it just to make sure:
> >
> > We can track LoD history (formerly known as CopyFrom history) by
> > associating a particular copyfrom fact with a NodeID. Since in
> > "NodeID.TransactionID", the NodeID stays constant for the life
> > of the node, the association is constant time/space -- it only
> > to be recorded once, when the new NodeID is first generated, and
> > thereafter it can be looked up via that NodeID.
> >
> > This makes it easy to tell that a particular node deep within a
> > copied tree is a copy (just look for LoD history here, then walk
> > parents doing same). O(n), as you say, but no big deal, because
> > is just directory depth. Not only is this useful for "svn log"
> > other reporting mechanisms, but we can also use it to keep
> > from varying counterintuitively, thusly: when committing a change
> > to X.Q, we would normally create X.(R) (where R is some
> > TransactionID greater than Q), but if there's LoD history on X.Q
> > and the original also has NodeID X, then we want to reserve the X
> > line for the original, so we create Y.R instead.
> >

The text in this second paragraph about how we decide to create a new
NodeID fudges a some of the details. For the sake of being utterly picky
about the specific details, I'll fill in the missing bits.

Initial state:
  We have two repository paths: P1 and P2.
  P2 is in a different LoD than P1.
  P2 points at the same NodeRevision (X.Q) that P1 points at because P2
hasn't been modified yet.

User action:
The user submits a change for P2.

Server action:
While doing our various processing for commits we'll be walking the
directory hierarchy already. We can incrementally keep the LoD
information for the current directory.

When we come to the change reported for P2 we do the following:
  P2NodeID = NodeID that P2 points at
  If P2 has a LOD or we found a LoD in the directory crawl:
     SrcPath = The source path of the LoD
     P2BranchRelativePath = P2 with the LoD prefix stripepd
     PreBranchPath = SrcPath + '\' + P2BranchRelativePath
     # PreBranchPath == P1 here btw.
     PreBranchNodeID = NodeID that PreBranchPath points at.
     If PreBranchNodeID == P2NodeID:
        # We've now proved that P2 needs a new NodeID.
          P2NodeID = next available NodeID.

Does this help clear things up?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 15 01:58:14 2002

This is an archived mail posted to the Subversion Dev mailing list.