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

Re: SVK & SVN co woes [was: SVN 'entries' Hacking - Safe?]

From: Chris Horn <chris_at_beefstew.net>
Date: 2007-11-29 06:21:05 CET

John Peacock wrote:
> For purposes of this discussion, you can ignore that SVK can *also*
> mirror a remote Subversion server. The key difference for you here is
> that SVK will allow you to checkout into an existing directory tree and
> subsequently manage any and/or all files from that checkout.

So, I took your advice and installed SVK. Unfortunately, I've run into some
trouble. I know that this is the wrong list, but I'm hoping for a quick save...

The problem is that SVK won't checkout over an existing file structure (my
original problem with SVN -- something that doesn't seem to work in 1.4.5, either).

1. Create folder foo in local test directory
2. svk co svn+ssh://user@host.com/var/svn/tags/rel-1-0-0/foo .
Checkout path foo already exists.
3. NO GO

Do you know how I'm supposed to checkout a repository over an existing file
structure?

> If I were doing this, I would create an empty path in an SVK repo and
> check it out over the top of /etc, then 'svk add' the files I wanted to
> manage from the repository (e.g. not the files that the operating system
> or GUI management tools mess with directly). From that point on, those
> files and only those files would be under version control. Whether you
> mirror that information to another repo is a completely independent
> decision.

Unfortunately, I don't have the option of starting with a blank SVN repository.

Many thanks for everyone's help so far,
Chris

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 29 06:16:32 2007

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.