[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Doing svn checkouts on top of svn checkouts?????

From: Geoff Hoffman <ghoffman_at_cardinalpath.com>
Date: Mon, 11 Jul 2011 18:20:41 -0700

This is a feature, yes. Subversion does allow your working copy to point to
> 1 svn path.

Sounds a lot like when you use svn:externals. This may be the more
"standard" way of achieving what you're talking about.

If you change code in [yourstuff] and [stuff pointing back to external's
home] then when you commit (in NetBeans anyway) it will show you a warning
about committing to multiple branches.

You can also svn update a specific file/dir to a specific (older, non-HEAD)
revision, though I've rarely if ever done this.

HTH-

On Mon, Jul 11, 2011 at 5:08 PM, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:

> I just ran into a fascinating configuration where someone is doing
> Subversion checkouts on top of existing Subversion checkouts. I'd
> never even *THOUGHT* of pulling such a stunt, but it's apparently
> workable.
>
> I'm concerned, though, that any change in the source of the Subversion
> checkout to a branch or tag will simply break things, or any
> reloaction of the source repository component will also break things.
> I'm also concerned that, should someone mix and match components
> inside the working copy manually, things will break in fascinating
> fashion, or that locally modified components will only be updated, not
> actually replaced.
>
> Has anyone been using this feature? It seems to work to do an "svn
> checkout" on top of an existing working copy of the same URL or
> earlier releases, but I've not tried rolling back the revision number
> or other games. I could spend a bunch of time checkout out border
> cases, but would welcome insights.
>
Received on 2011-07-12 03:21:21 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.