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

Fixing issue #842

From: <cmpilato_at_collab.net>
Date: 2002-08-02 23:04:19 CEST

A reminder of the bug:

   Given a repos directory A and child node A/foo:
      - copy A/foo A/foo2; commit
      - copy A A2; commit
      - vi A2/foo A2/foo2; commit

   The bug manifests itself in an error about two nodes trying to
   acquire the same new node revision ID. The root cause, though, is
   that filesystem is trying to treat A2/foo and A2/foo2 as being on
   the same branch, despite the fact that they are not. 'A/foo' and
   'A/foo2' were on different branches, then we branched their parent
   directory 'A', so 'A2/foo' and 'A2/foo2' should also be on
   different branches.

After chatting with Bitt Tutt about this bug, I've set out to code the

   Instead of copied subtree nodes blindly assuming the Copy Id of
   their parents, some determination about whether or not that node is
   on the same branch as the parent must happen. If the child is on
   the same branch as the parent, it assumes the parent's Copy Id;
   else, a new Copy Id is generated for it.

An implementation question lingers:

   In generating this new Copy Id for the branched branched child
   node, should that Copy Id look like a first-class COPY or not.
   That is, should the question svn_fs_copied_from () on that node
   reply that yes, that node was copied though no svn_fs_copy()
   operation actually occured as part of that revision? Or, should we
   populate the new row in the `copies' table with some magic that
   means "This wasn't a real copy, just a new ID handed out to a
   branch of a branch"?

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 2 23:04:55 2002

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.