Deadlocking sandbox?

[Pierre Asselin]

Suppose I have this in my modules file:

    common      path/to/common/files
    project_A   path/to/A       &common
    project_B   path/to/B       &common

So far, so good.  I just have two projects, A and B, that share a
common subtree through the amperstand module "common".  Completely
normal.  But what if I add this?

    gotcha      &project_A &project_B

A checked-out copy of "gotcha" will have two independent copies of the
"common" subtree.  My question:

    Can I do a "cvs commit" from the top of "gotcha" ?

It seems that CVS will want to acquire two write locks on the "common"
tree in the repository and irremediably deadlock itself.  Is that
correct, or is CVS smart enough to recognize the first lock as its
own?

(I'm assuming that I'll be able to check out "gotcha" in the first
place, but that only seems to involve multiple *read* locks, so it
should be OK.)

To those who say "If you do that, you deserve whatever happens to
you" I reply "I agree".  But I have a case where such a sandbox would
actually be useful.  I would want to update from the top of "gotcha",
but not do anything that requires write locks.  Any advice?

Maybe I'll try it on a test repository.

--
Pierre Asselin
Westminster, Colorado


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----