[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Deadlocking sandbox?
From: |
Pierre Asselin |
Subject: |
Deadlocking sandbox? |
Date: |
12 Nov 2001 21:07:09 -0600 |
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! =-----
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Deadlocking sandbox?,
Pierre Asselin <=