So I've been trying to figure out if we need a "soft move" copy type,
similar to the way we currently have a "soft copy", and I'm a bit
lost, mainly because in order to really answer that question I need to
understand soft copies, and while cmpilato has been nice enough to
explain them to me at least twice now, it's still a rather fuzzy topic
for me.
Here's my current understanding (thanks to some help from maxb on IRC
puzzling out the operations required to create them and some combing
through the code in libsvn_fs_base/tree.c to see how they're used):
So soft copy records in the copies table are different from regular
copy records. While you create a regular copy record every time you
copy a node in the filesystem, soft copies are only created in special
situations in response to other filesystem operations. Specifically,
one is created when you've got a node that's been copied, it's then a
part of another copy operation (i.e. you copied its parent directory),
and then you modify the new version of it. That's confusing, let's
look at the actual process that creates one.
(Thanks to maxb for coming up with this)
svnadmin create repos
svn co file://`pwd`/repos wc
cd wc
svn mkdir trunk tags branches
svn ci -m""
svn up
touch trunk/foo
svn add trunk/foo
svn ci -m""
svn up
svn cp trunk/foo trunk/bar
svn ci -m""
svn up
svn cp trunk branches/a-branch
svn ci -m""
svn up
echo "content" > branches/a-branch/bar
svn ci -m""
Ok, when we edited a-branch/bar and committed the change it introduced
a soft copy in the filesystem, so while from the user's perspective it
just looks like an edit, in the underlying filesystem it is actually a
copy of the previous node and then a modification.
Now, that's what creates one of these things, but why is it done that
way? Well, this is where I get fuzzy. The fs-structure document
implies that it's because in that sort of situation the file in
question is on a different "branch" (using the low level form of that
word, not the 'a directory in branches/' form of it) than its parent
directory. I'm not really clear why that matters though.
Let's take another approach. What is the effect of encountering a
soft copy record in the copies table as opposed to a regular copy
record? Well, in examine_copy_inheritance when we see one we just
recurse up to our parent directory and examine it's copy data instead
of using the one we're at. So it's basically ignored. Similarly in
the history_prev code when we get a soft copy we end up returning a
history object that's ignored and never actually shown to the user (at
least from what I can see, although I could be reading this wrong).
So what's the point here? Is this one of those cases where if we
didn't do these gymnastics we'd end up reusing primary keys or
something? And if so, does the same sort of problem occur with moves
as can happen with copies?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 15 01:34:26 2006