transaction roots

I've been creating transactions based on the "youngest" revision, and then
applying changes to that. I was wondering if anybody sees a problem with
doing that.

[ this is contrary to libsvn_fs/editor.c creating transactions based on
  arbitrary revisions. ]

Specifically, my thinking with using the youngest revision is simply that a
commit must be made against the youngest revision. If the user wants to
change file REV:PATH, then that file exists in one of two states within the
youngest revision tree:

1) the youngest tree has the same file as REV:PATH. it is okay to change.
2) the youngest tree shows a change since REV:PATH, so the client is out of
   date and needs to be updated.

I don't see that grabbing an old revision is all that helpful.

There are potentially intervening tree changes that could interfere, but (at
least in the DAV case), I can detect those. Recall that I store the ID for
each node. If 3:/FOO/BAR is different from 4:/FOO/BAR because of changes at
the FOO level, then I'll see the ID change and punt.

And note that a user cannot commit against 3:/FOO/BAR anyways, because it is
out of date.

I guess it is conceivable for something like this to happen:

  REV3/
    FOO/
      BAR(4.1)

  REV4/
    FOO/
      BAR(71.6)

  REV5/
    FOO/
      BAR(4.1)

If a user has 3:/FOO/BAR, and the latest rev is 5, then a commit to BAR will
actually succeed since it is "up to date" :-)

Can anybody see a problem with creating transactions based on the latest,
and verifying that the base of each desired change matches that within the
latest tree?

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/