confusing E195012 error: Unable to find repository location.(when location exists)

2013-03-15 Thread Tom

Hi mailing list :)

Please, help me to find out what is going on in our repository. I am
preparing some automatic tool
to work with svn and there is one thing, which is confusing to me.

I want to do checkout to some revision:
If I use peg revision everything is ok as expected:

svn co https:\\...\branch10@11893  -r 11893

But when I try to ommit peg revision:

svn co https:\\...\branch10  -r 11893

E195012 Unable to find out repository location occurs for
https:\\...\branch10 occurs. Problem is that as I
browse the repository in Tortoise svn Repo Browser for revision 11893
theres IS path https:\\...\\branch10.
(even that is was 11894 renamed and the new https:\\...\branch7 was
copied from another path in 11895.


I would consider it as a feature but when I do the same thing with
another branch in our respository. I obtain different result:

svn co https:\\...\branch7@11893  -r 11893

(again works fine. checkouts branch7 in 11893 revision.)

svn co https:\\...\branch7  -r 11893

This command will end without error and checkouts the branch from
which the branch7 was copied.
I am confused why there is not the same result for the branch10??

Here is some screenshot from TortoiseSvn revision graph, maybe there
will be hidden some answer to this:

http://subversion.1072662.n5.nabble.com/file/n179019/coBehavior.png 


Thanks in advance.
Tom











--
View this message in context: 
http://subversion.1072662.n5.nabble.com/confusing-E195012-error-Unable-to-find-repository-location-when-location-exists-tp179019.html
Sent from the Subversion Users mailing list archive at Nabble.com.


Re: confusing E195012 error: Unable to find repository location.(when location exists)

2013-03-15 Thread Thorsten Schöning
Guten Tag Tom,
am Freitag, 15. März 2013 um 11:48 schrieben Sie:

 But when I try to ommit peg revision:

 svn co https:\\...\branch10  -r 11893

co is the wrong command for committing, you need ci. Besides that, you
can' commit to old revisions, only to HEAD.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow



Re: confusing E195012 error: Unable to find repository location.(when location exists)

2013-03-15 Thread Tom
Hi Thorsten,

sorry to confuse You, I was meaning checkout command

 But when I try to ommit peg revision: 
this was meant as  try to omit peg revision:  like do without peg
revision - 
Please excuse my bad English :)

So my post was all about checkout. Although I think the info command is
behaving the same way (with respect to this problem) ... 

Thanks to reply :)
Tom



--
View this message in context: 
http://subversion.1072662.n5.nabble.com/confusing-E195012-error-Unable-to-find-repository-location-when-location-exists-tp179019p179021.html
Sent from the Subversion Users mailing list archive at Nabble.com.


Re: confusing E195012 error: Unable to find repository location.(when location exists)

2013-03-15 Thread C. Michael Pilato
On 03/15/2013 06:48 AM, Tom wrote:
 
 Hi mailing list :)
 
 Please, help me to find out what is going on in our repository. I am
 preparing some automatic tool
 to work with svn and there is one thing, which is confusing to me.
 
 I want to do checkout to some revision:
 If I use peg revision everything is ok as expected:
 
 svn co https:\\...\branch10@11893  -r 11893
 
 But when I try to ommit peg revision:
 
 svn co https:\\...\branch10  -r 11893
 
 E195012 Unable to find out repository location occurs for
 https:\\...\branch10 occurs.

Your first syntax instructs Subversion to:

   - find the 'line of history' that intersects the path
 https:\\...\branch10 in revision 11893 (the @ rev)
   - walk that line of history until you get to revision 11893
 (the -r rev)
   - checkout that object (regardless of its path in the -r
 revision)

As you can tell, the second step of that set of instructions seems
redundant, right?  And in fact, it *is* redundant.  Your command-line could
have just been:

   svn co https:\\...\branch10@11893   # without the -r

The second command syntax instructs Subversion to:

   - find the 'line of history' that intersects the path
 https:\\...\branch10 in HEAD (the implied @ rev)
   - walk that line of history until you get to revision 11893
 (the -r rev)
   - checkout that object (regardless of its path in the -r
 revision)

 Problem is that as I
 browse the repository in Tortoise svn Repo Browser for revision 11893
 theres IS path https:\\...\\branch10.

If I understand you correctly, back in r11893 there was a branch10.
Later, that branch10 was moved elsewhere and a new branch10 came into
being.  That's fine.

The question is:  what is the very first revision for the directory which is
called branch10 in HEAD?  You should be able to get the answer using this
command:

   svn log -q -r1:HEAD --limit 1 https:\\...\branch10

If the answer is a revision that's younger than r11893, then that explains
why Subversion has complained.


-- 
C. Michael Pilato cmpil...@collab.net
CollabNet  www.collab.net  Enterprise Cloud Development



signature.asc
Description: OpenPGP digital signature


Re: confusing E195012 error: Unable to find repository location.(when location exists)

2013-03-15 Thread Tom
Hi Michael.

 Your first syntax instructs Subversion to:

- find the 'line of history' that intersects the path
  https:\\...\branch10 in revision 11893 (the @ rev)
- walk that line of history until you get to revision 11893
  (the -r rev)
- checkout that object (regardless of its path in the -r
  revision)

Thanks for nice explanation. I was imagining the algorithm (slightly
different):
 - find the object, which was  on path https:\\...\branch10 in
revision 11893
 - backtrack the object to the right revision (the -r rev)
 - checkout object which was backtracked

which somehow brought me to the idea, that -r rev is here necesary, even if
it has the same value as @rev.
So i will stick to Yours explanation wich is apparantly more correct :)

 The question is:  what is the very first revision for the directory which
 is
 called branch10 in HEAD?  You should be able to get the answer using
 this
 command:

svn log -q -r1:HEAD --limit 1 https:\\...\branch10

I tried this for both my branches:
svn log -q -r1:HEAD --limit 1 https:\\...\branch10
svn log -q -r1:HEAD --limit 1 https:\\...\branch7

and for both of them I get revision: r69
Indeed both branches have the common ancester.

 If the answer is a revision that's younger than r11893, then that explains
 why Subversion has complained.

For both the branches the revision is older.
So, If I get it right, the expected behaviour in this case is: there is
checkouted 
object found in the 'line of history'
(in my case of https:\\...\branch7  the object was in r11893 in ancestor
branch).
This is great, because this was excpected also by me :)  

There is one remaining question: Why is this not working for the second
branch:
https:\\...\branch10 (error E195012 occures).

Maybe there could arise some other complications about which I dont know ...
Nevertheless I am glad to know about the expected behavior.

Tom







--
View this message in context: 
http://subversion.1072662.n5.nabble.com/confusing-E195012-error-Unable-to-find-repository-location-when-location-exists-tp179019p179026.html
Sent from the Subversion Users mailing list archive at Nabble.com.


Re: confusing E195012 error: Unable to find repository location.(when location exists)

2013-03-15 Thread C. Michael Pilato
On 03/15/2013 11:02 AM, Tom wrote:
 The question is:  what is the very first revision for the directory which is
 called branch10 in HEAD?  You should be able to get the answer using this
 command:

svn log -q -r1:HEAD --limit 1 https:\\...\branch10
 
 I tried this for both my branches:
 svn log -q -r1:HEAD --limit 1 https:\\...\branch10
 svn log -q -r1:HEAD --limit 1 https:\\...\branch7
 
 and for both of them I get revision: r69
 Indeed both branches have the common ancester.
 
 If the answer is a revision that's younger than r11893, then that explains
 why Subversion has complained.
 
 For both the branches the revision is older.
 So, If I get it right, the expected behaviour in this case is: there is
 checkouted  object found in the 'line of history'
 (in my case of https:\\...\branch7  the object was in r11893 in ancestor
 branch). This is great, because this was excpected also by me :)  
 
 There is one remaining question: Why is this not working for the second
 branch:
 https:\\...\branch10 (error E195012 occures).
 
 Maybe there could arise some other complications about which I dont know ...
 Nevertheless I am glad to know about the expected behavior.

If you were able to run 'svn log' all the way back to revision 69, then I
would expect I would expect that your checkouts would all have worked, then.
 Weird.  I, too, wonder what's going on...


-- 
C. Michael Pilato cmpil...@collab.net
CollabNet  www.collab.net  Enterprise Cloud Development



signature.asc
Description: OpenPGP digital signature


Need to restructure repo folders: Problem: SVN COPY is recursive

2013-03-15 Thread Tim.Williams
Hi folks,

We are changing our folder structure in the SVN repository and need to map 
content from old folders to the new folders.  I was investigating the use of 
SVN COPY but the command is recursive, which leads to problems for us.
For example, let's say our structure looks like:

Original Folders
\a
\a\b
\a\b\c

And we are moving to a new structure where content from \a is copied to \d, \b 
to \e and \c also to \e:
New Folders
\d
\d\e

I can't do a SVN COPY of \b to \e because I would get:
\d\e\c

The only solution I can think of is to script a copy process on a file-by-file 
basis by first getting a list of files in folder \c, then SVN COPY each file 
individually into folder \e.  Repeat for all folders. I can this in PERL but it 
seems like a long journey to get to the result...

What am I missing?  Is my approach flawed?

Note that we want to keep the original structure in place as well as have the 
new one which is why I am playing with COPY instead of MOVE or SWITCH.

Cheers,

Tim


UCB BIOSCIENCES, Inc.
Mail P.O. Box 110167 - Research Triangle Park - NC 27709 - USA
Via Courier 8010 Arco Corporate Drive - Suite 100 - Raleigh - NC 27617 - USA
Phone +1 919 767 2555 - Fax +1 919 767 2570

(Ref: #*UBI0111) [Ref-UBI0111]

Legal Notice: This electronic mail and its attachments are intended solely for 
the person(s) to whom they are addressed and contain information which is 
confidential or otherwise protected from disclosure, except for the purpose for 
which they are intended. Dissemination, distribution, or reproduction by anyone 
other than the intended recipients is prohibited and may be illegal. If you are 
not an intended recipient, please immediately inform the sender and return the 
electronic mail and its attachments and destroy any copies which may be in your 
possession. UCB screens electronic mails for viruses but does not warrant that 
this electronic mail is free of any viruses. UCB accepts no liability for any 
damage caused by any virus transmitted by this electronic mail. (Ref: #*UG1107) 
[Ref-UG1107]



RE: Need to restructure repo folders: Problem: SVN COPY is recursive

2013-03-15 Thread Bob Archer
 Hi folks,
 
 We are changing our folder structure in the SVN repository and need to map
 content from old folders to the new folders.  I was investigating the use of 
 SVN
 COPY but the command is recursive, which leads to problems for us.
 For example, let's say our structure looks like:
 
 Original Folders
 \a
 \a\b
 \a\b\c
 
 And we are moving to a new structure where content from \a is copied to \d, \b
 to \e and \c also to \e:
 New Folders
 \d
 \d\e
 
 I can't do a SVN COPY of \b to \e because I would get:
 \d\e\c
 The only solution I can think of is to script a copy process on a 
 file-by-file basis
 by first getting a list of files in folder \c, then SVN COPY each file 
 individually
 into folder \e.  Repeat for all folders. I can this in PERL but it seems like 
 a long
 journey to get to the result.
 
 What am I missing?  Is my approach flawed?

That's pretty common because after all, a does contain folder b so when you 
copy a it is going to copy b.

All you have to do is work bottom up

copy \a\b\c \e
copy \a\b \e

Then of course you would have to remove \c from \e.  Also, the svn copy command 
doesn't have advanced options like your shell does to copy files exclusive of 
folders and stuff. 

Hth,
BOb

 Note that we want to keep the original structure in place as well as have the
 new one which is why I am playing with COPY instead of MOVE or SWITCH.


Re: Need to restructure repo folders: Problem: SVN COPY is recursive

2013-03-15 Thread C. Michael Pilato
On 03/15/2013 03:11 PM, tim.willi...@ucb.com wrote:
 The only solution I can think of is to script a copy process on a
 file-by-file basis by first getting a list of files in folder \c, then SVN
 COPY each file individually into folder \e.  Repeat for all folders. I can
 this in PERL but it seems like a long journey to get to the result…

I confess I got a bit lost in your description, but many times when folks
have had major directory reorganization to do in Subversion, they've found
the 'svnmucc' took helpful.  svnmucc will be shipped as a first-class binary
in Subversion 1.8, but has existed in Subversion's tools/ directory for many
years.  I recently(ish) documented for Version Control With Subversion the
gist of the tool.  See
http://svnbook.red-bean.com/nightly/en/svn.advanced.working-without-a-wc.html#svn.advanced.working-without-a-wc.svnmucc
for that write-up.

-- 
C. Michael Pilato cmpil...@collab.net
CollabNet  www.collab.net  Enterprise Cloud Development



signature.asc
Description: OpenPGP digital signature


Re: confusing E195012 error: Unable to find repository location.(when location exists)

2013-03-15 Thread Daniel Shahaf
C. Michael Pilato wrote on Fri, Mar 15, 2013 at 09:42:53 -0400:
 On 03/15/2013 06:48 AM, Tom wrote:
  
  Hi mailing list :)
  
  Please, help me to find out what is going on in our repository. I am
  preparing some automatic tool
  to work with svn and there is one thing, which is confusing to me.
  
  I want to do checkout to some revision:
  If I use peg revision everything is ok as expected:
  
  svn co https:\\...\branch10@11893  -r 11893
  
  But when I try to ommit peg revision:
  
  svn co https:\\...\branch10  -r 11893
  
  E195012 Unable to find out repository location occurs for
  https:\\...\branch10 occurs.
 
 Your first syntax instructs Subversion to:
 
- find the 'line of history' that intersects the path
  https:\\...\branch10 in revision 11893 (the @ rev)
- walk that line of history until you get to revision 11893
  (the -r rev)
- checkout that object (regardless of its path in the -r
  revision)
 
 As you can tell, the second step of that set of instructions seems
 redundant, right?  And in fact, it *is* redundant.  Your command-line could
 have just been:
 
svn co https:\\...\branch10@11893   # without the -r
 
 The second command syntax instructs Subversion to:
 
- find the 'line of history' that intersects the path
  https:\\...\branch10 in HEAD (the implied @ rev)
- walk that line of history until you get to revision 11893
  (the -r rev)
- checkout that object (regardless of its path in the -r
  revision)
 
  Problem is that as I
  browse the repository in Tortoise svn Repo Browser for revision 11893
  theres IS path https:\\...\\branch10.
 
 If I understand you correctly, back in r11893 there was a branch10.
 Later, that branch10 was moved elsewhere and a new branch10 came into
 being.  That's fine.
 
 The question is:  what is the very first revision for the directory which is
 called branch10 in HEAD?  You should be able to get the answer using this
 command:
 
svn log -q -r1:HEAD --limit 1 https:\\...\branch10

Need to pass --stop-on-copy too

 
 If the answer is a revision that's younger than r11893, then that explains
 why Subversion has complained.
 
 
 -- 
 C. Michael Pilato cmpil...@collab.net
 CollabNet  www.collab.net  Enterprise Cloud Development
 




RE: Need to restructure repo folders: Problem: SVN COPY is recursive

2013-03-15 Thread Tim.Williams
I am not very good at giving examples on a Friday afternoon, admittedly.  I 
will try again.

Original Folders
\Barn\livestockNames.txt
\Barn\chickens\chickenNames.txt
\Barn\chickens\food\chickenFeed.txt

New Structure I want:
\NewBarn\livestockNames.txt
\NewBarn\birds\chickenNames.txt
\NewBarn\birds\chickenFeed.txt

If I use SVN COPY to copy chickenNames.txt to the new folder:

svn copy \Barn\chickens\  \NewBarn\birds\

I will get:
\NewBarn\birds\food\chickenFeed.txt

and I don’t want that folder called \food and its content.

Ugh. This is another bad analogy. It is much more complicated because I have 
MANY files in each folder remapped to many different folders and subfolders, 
which is why I had hoped to use a non-recursive way to getting just the folder 
contents and not subfolders.

I will look into svnmucc.  Thanks for the tip!

Tim

UCB BIOSCIENCES, Inc.
Mail P.O. Box 110167 - Research Triangle Park - NC 27709 - USA
Via Courier 8010 Arco Corporate Drive - Suite 100 - Raleigh - NC 27617 - USA
Phone +1 919 767 2555 - Fax +1 919 767 2570

(Ref: #*UBI0111) [Ref-UBI0111]

Legal Notice: This electronic mail and its attachments are intended solely for 
the person(s) to whom they are addressed and contain information which is 
confidential or otherwise protected from disclosure, except for the purpose for 
which they are intended. Dissemination, distribution, or reproduction by anyone 
other than the intended recipients is prohibited and may be illegal. If you are 
not an intended recipient, please immediately inform the sender and return the 
electronic mail and its attachments and destroy any copies which may be in your 
possession. UCB screens electronic mails for viruses but does not warrant that 
this electronic mail is free of any viruses. UCB accepts no liability for any 
damage caused by any virus transmitted by this electronic mail. (Ref: #*UG1107) 
[Ref-UG1107]



Re: Need to restructure repo folders: Problem: SVN COPY is recursive

2013-03-15 Thread olli hauer
On 2013-03-15 21:07, tim.willi...@ucb.com wrote:
 I am not very good at giving examples on a Friday afternoon, admittedly.  I 
 will try again.
 
 Original Folders
 \Barn\livestockNames.txt
 \Barn\chickens\chickenNames.txt
 \Barn\chickens\food\chickenFeed.txt
 
 New Structure I want:
 \NewBarn\livestockNames.txt
 \NewBarn\birds\chickenNames.txt
 \NewBarn\birds\chickenFeed.txt
 
 If I use SVN COPY to copy chickenNames.txt to the new folder:
 
 svn copy \Barn\chickens\  \NewBarn\birds\
 
 I will get:
 \NewBarn\birds\food\chickenFeed.txt
 
 and I don’t want that folder called \food and its content.
 

Hm, why do you copy the folder instead the single file ?

 svn copy \Barn\chickens\chickenFeed.txt  \NewBarn\birds\

If you have a bunch of files you can do this quickly with a wrapper script


Re: Need to restructure repo folders: Problem: SVN COPY is recursive

2013-03-15 Thread C. Michael Pilato
On 03/15/2013 04:07 PM, tim.willi...@ucb.com wrote:
 I am not very good at giving examples on a Friday afternoon, admittedly.  I 
 will try again.
 
 Original Folders
 \Barn\livestockNames.txt
 \Barn\chickens\chickenNames.txt
 \Barn\chickens\food\chickenFeed.txt
 
 New Structure I want:
 \NewBarn\livestockNames.txt
 \NewBarn\birds\chickenNames.txt
 \NewBarn\birds\chickenFeed.txt
 
 If I use SVN COPY to copy chickenNames.txt to the new folder:
 
 svn copy \Barn\chickens\  \NewBarn\birds\
 
 I will get:
 \NewBarn\birds\food\chickenFeed.txt
 
 and I don’t want that folder called \food and its content.
 
 Ugh. This is another bad analogy. It is much more complicated because I have 
 MANY files in each folder remapped to many different folders and subfolders, 
 which is why I had hoped to use a non-recursive way to getting just the 
 folder contents and not subfolders.
 
 I will look into svnmucc.  Thanks for the tip!

Just to be clear:  svnmucc will also do recursive copies.  The benefit it
brings is the ability to do several remote commit-ish operations in a single
revision (where 'svn' can only do a single thing -- or at least a single
type of thing -- at a time).

-- 
C. Michael Pilato cmpil...@collab.net
CollabNet  www.collab.net  Enterprise Cloud Development



signature.asc
Description: OpenPGP digital signature


RE: Need to restructure repo folders: Problem: SVN COPY is recursive

2013-03-15 Thread Tim.Williams
Yes, it appears I am headed toward a wrapper script to copy one file at a time. 
 I wanted to make sure I was not missing something in SVN that would make it 
easier (a non-recursive copy, or something in svnmucc where I could copy a 
bunch a files and commit them all in a single new revision, for example).

It appears that I am stuck creating a new revision for every single file I need 
to move.  This will make the SVN Log history long and boring, but it appears 
there is not much else that can be done if my users want to retain the 
development history. Otherwise I would just SVN export it, remap it in a work 
area and commit it all in one big go.

Thanks for the sanity check, folks.

Tim


UCB BIOSCIENCES, Inc.
Mail P.O. Box 110167 - Research Triangle Park - NC 27709 - USA
Via Courier 8010 Arco Corporate Drive - Suite 100 - Raleigh - NC 27617 - USA
Phone +1 919 767 2555 - Fax +1 919 767 2570

(Ref: #*UBI0111) [Ref-UBI0111]

Legal Notice: This electronic mail and its attachments are intended solely for 
the person(s) to whom they are addressed and contain information which is 
confidential or otherwise protected from disclosure, except for the purpose for 
which they are intended. Dissemination, distribution, or reproduction by anyone 
other than the intended recipients is prohibited and may be illegal. If you are 
not an intended recipient, please immediately inform the sender and return the 
electronic mail and its attachments and destroy any copies which may be in your 
possession. UCB screens electronic mails for viruses but does not warrant that 
this electronic mail is free of any viruses. UCB accepts no liability for any 
damage caused by any virus transmitted by this electronic mail. (Ref: #*UG1107) 
[Ref-UG1107]



Re: confusing E195012 error: Unable to find repository location.(when location exists)

2013-03-15 Thread C. Michael Pilato
On 03/15/2013 03:58 PM, Daniel Shahaf wrote:
 C. Michael Pilato wrote on Fri, Mar 15, 2013 at 09:42:53 -0400:
 The question is:  what is the very first revision for the directory which is
 called branch10 in HEAD?  You should be able to get the answer using this
 command:

svn log -q -r1:HEAD --limit 1 https:\\...\branch10
 
 Need to pass --stop-on-copy too

Well, actually, for the information I was seeking, --stop-on-copy *could*
yield misleading results.

However, your mentioning it does call to mind what *might* be happening -- a
history gap in the lineage of branch10 which straddles the revision of
interest (r11893).  In other words, if there's a revision which appears in
the output of `svn log -qv https:\\...\branch10` like:

   r11895 | ...

   Changed paths:
  A  ...branch10 (from /some/other/path, r11890)

where an object in a pre-11893 rev was copied in a post-11893 rev, that
would also produce this symptom.

-- 
C. Michael Pilato cmpil...@collab.net
CollabNet  www.collab.net  Enterprise Cloud Development



signature.asc
Description: OpenPGP digital signature


Re: Need to restructure repo folders: Problem: SVN COPY is recursive

2013-03-15 Thread olli hauer
On 2013-03-15 21:30, tim.willi...@ucb.com wrote:
 Yes, it appears I am headed toward a wrapper script to copy one file at a 
 time.  I wanted to make sure I was not missing something in SVN that would 
 make it easier (a non-recursive copy, or something in svnmucc where I could 
 copy a bunch a files and commit them all in a single new revision, for 
 example).
 
 It appears that I am stuck creating a new revision for every single file I 
 need to move.  This will make the SVN Log history long and boring, but it 
 appears there is not much else that can be done if my users want to retain 
 the development history. Otherwise I would just SVN export it, remap it in a 
 work area and commit it all in one big go.
 
 Thanks for the sanity check, folks.
 
 Tim

Maybe something to test (but maybe totally wrong ...)
 svn move \Barn\chickens\food \tmp\
 svn copy \Barn\chickens\ \NewBarn\birds\
 svn revert \Barn\chickens\food
 svn commit

Increasing the revision will be done only if you do a commit.


Re: Need to restructure repo folders: Problem: SVN COPY is recursive

2013-03-15 Thread Sven Uhlig
Am 15.03.2013 21:30, schrieb tim.willi...@ucb.com:
 Yes, it appears I am headed toward a wrapper script to copy one file at a 
 time.  I wanted to make sure I was not missing something in SVN that would 
 make it easier (a non-recursive copy, or something in svnmucc where I could 
 copy a bunch a files and commit them all in a single new revision, for 
 example).
 
 It appears that I am stuck creating a new revision for every single file I 
 need to move.  This will make the SVN Log history long and boring, but it 
 appears there is not much else that can be done if my users want to retain 
 the development history. Otherwise I would just SVN export it, remap it in a 
 work area and commit it all in one big go.
 

I dont think you have to create a new revision for each single file.

Just do svn copy and then do a svn delete for all files that you dont
want to have copied.

e.g.

svn copy /foo/bar /new
svn delete /new/bar/baz

svn copy /foo/qwx /new/bar
svn delete /new/bar/qwx/abc

...

svn commit



Re: Need to restructure repo folders: Problem: SVN COPY is recursive

2013-03-15 Thread Thorsten Schöning
Guten Tag tim.willi...@ucb.com,
am Freitag, 15. März 2013 um 21:30 schrieben Sie:

 It appears that I am stuck creating a new revision for every single
 file I need to move.

As already said, you aren't, just checkout a working copy, do you
copies, moves and deletes and commit after you are finished. If you
are using Windows you can rework your directory structure really fast
with TortoiseSVN: Just right click and DragDrop will do most of the
work.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow