Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: local policy)
Date: Sun, 7 Jul 2013 17:44:24 +0200
From: Stefan Sperling <stsp@elego.de>
To: Frank Loeffler <knarf@cct.lsu.edu>
Cc: users@subversion.apache.org
Subject: Re: Parallel checkout within checkout
Message-ID: <20130707154424.GA27437@ted.stsp.name>
Mail-Followup-To: Frank Loeffler <knarf@cct.lsu.edu>,
	users@subversion.apache.org
References: <20130706113927.GA25200@topf.wg>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130706113927.GA25200@topf.wg>
User-Agent: Mutt/1.5.21 (2010-09-15)

On Sat, Jul 06, 2013 at 06:39:27AM -0500, Frank Loeffler wrote:
> My theory is that the checkout of the contained repository tries to look
> into .svn of the containing repository, and finds it 'currently used'.

You mean "working copy" (the copy being checked out), not "repository"
(the database we check out from).

Yes, I believe what you are seeing is that the nested 'svn checkout'
operation ends up using the .svn directory of the enclosing working
copy.

> This was not the case for versions <1.7, maybe because these didn't use
> a 'central' .svn directory.
> 
> I would now argue that this is a regression, since svn <1.7 worked fine
> in this scenario, while >=1.7 doesn't.

I would argue that you were relying on an implementation detail.
Nowhere does the documentation mention or even recommend what you
are doing.
 
> Ways to reproduce:
> 
> 1. svn co some_repo
> 2. interrupt during checkout (control-Z)
> 3. cd into new (partial) checkout
> 4. svn co some_other_repo

I have two suggestions:

When using 1.7 clients, run checkouts in parallel but into temporary
directories that are not nested. When done, move the temporary working
copies into each other to create the nested structure. This should work.
If you keep all temp working copies on the same disk then moving them
should be very cheap.

If you use HTTP to access the repository, my other suggestion is to update
both clients and server to 1.8 and test checkout performance. You might
benefit from the new HTTP client layer (serf) in skelta mode, which might
improve throughput to the point where you don't need to checkout different
working copies in parallel for performance reasons. See here for details:
http://subversion.apache.org/docs/release-notes/1.8.html#neon-deleted