Nathan Hartman:
> Because '-r' tells SVN to look for that path in the HEAD
> revision and then follow it back to the specified
> revision.
>
> Try using a peg revision instead:
> svn switch ^^/Client/B1/Addons/AddCost/@1431 --ignore-ancestry
>
> See: http://svnbook.red-bean.com/en/1.7/svn.advanced
On Wed, Jan 13, 2021 at 10:59 AM Anton Shepelev wrote:
> I want to `switch' to a location that existsed in a previous
> revision, but has since been moved. I invoke:
>
>svn switch -r 1431 ^^/Client/B1/Addons/AddCost/ --ignore-ancestry
>
> and receive:
>
>svn: E160013: '/svn/Sources/!svn/r
Hello, all
I want to `switch' to a location that existsed in a previous
revision, but has since been moved. I invoke:
svn switch -r 1431 ^^/Client/B1/Addons/AddCost/ --ignore-ancestry
and receive:
svn: E160013: '/svn/Sources/!svn/rvr/6932/Client/B1/Addons/AddCost' path not
found
This p
Thanks Travis.
I thought this was a binary patch, not a source code patch. Now I realize that
since subversion gets compiled into a variety of executables a binary patch can
not be done. I do not wish to compile subversion. I have found that --force
works and I only need it if switching to a
intenance headache than it's worth.
--
Travis
>
>-Original Message-
>From: Travis Brown [mailto:trav...@travisbrown.ca]
>Sent: Saturday, August 24, 2013 5:58 PM
>To: Les Mikesell; Ryan Schmidt; Branko ??ibej; Subversion;
>d...@subversion.apache.org; John Maher
>
On 26.08.2013 15:31, John Maher wrote:
> Hello
>
> Can you provide me with a link as to how to apply this patch? When I search
> for applying a subversion patch all I get is stuff involving svn diff. I
> think the patch may be safer than using --force with switch for which all the
> ramificati
-
From: Travis Brown [mailto:trav...@travisbrown.ca]
Sent: Saturday, August 24, 2013 5:58 PM
To: Les Mikesell; Ryan Schmidt; Branko ??ibej; Subversion;
d...@subversion.apache.org; John Maher
Subject: Re: Switching
On Sat, Aug 24, 2013 at 09:53:14PM +0200, Stefan Sperling claimed:
>On Sat,
On Sun, Aug 25, 2013 at 03:44:05PM -0700, Travis Brown wrote:
> I took a brief look at the resolution code and found it to be a twisty
> maze of callbacks and workqueues. There didn't appear to be any existing
> infrastructure or obvious way to resolve the tree conflict on the
> directory and then
On Sun, Aug 25, 2013 at 11:46:11AM +0200, Stefan Sperling claimed:
>Looking at just one use case is not going to help us in the long term.
>And I don't think we should hard-code conflict resolution behaviour in
>the update/switch/merge logic.
>
>During 1.8 development, I did experiment with hard-co
On Sat, Aug 24, 2013 at 02:57:50PM -0700, Travis Brown wrote:
> On Sat, Aug 24, 2013 at 09:53:14PM +0200, Stefan Sperling claimed:
> >On Sat, Aug 24, 2013 at 12:26:41PM -0700, Travis Brown wrote:
> >> That's just overcomplicating the issue. This doesn't even need to
> >> become a tree conflict.
> >
On Sat, Aug 24, 2013 at 09:53:14PM +0200, Stefan Sperling claimed:
>On Sat, Aug 24, 2013 at 12:26:41PM -0700, Travis Brown wrote:
>> That's just overcomplicating the issue. This doesn't even need to
>> become a tree conflict.
>
>In my opinion it does need to be flagged as a conflict. Because we
>do
On 24.08.2013 21:26, Travis Brown wrote:
> On Sat, Aug 24, 2013 at 09:04:48PM +0200, Stefan Sperling claimed:
>> On Sat, Aug 24, 2013 at 10:22:41AM -0500, Les Mikesell wrote:
>>> Don't forget that it was subversion, not the user, that created the
>>> directory and abandoned it in the first place.
>
On Sat, Aug 24, 2013 at 02:18:59PM -0500, Les Mikesell wrote:
> On Sat, Aug 24, 2013 at 2:04 PM, Stefan Sperling wrote:
> > I hope that we will eventually extend tree conflict handling to the
> > point where it makes these kinds of situations trivial to resolve,
> > even for novice users. svn shou
On Sat, Aug 24, 2013 at 12:26:41PM -0700, Travis Brown wrote:
> That's just overcomplicating the issue. This doesn't even need to
> become a tree conflict.
In my opinion it does need to be flagged as a conflict. Because we
don't know what the contents of the incoming directory will be nor
what the
On Sat, Aug 24, 2013 at 09:04:48PM +0200, Stefan Sperling claimed:
>On Sat, Aug 24, 2013 at 10:22:41AM -0500, Les Mikesell wrote:
>> Don't forget that it was subversion, not the user, that created the
>> directory and abandoned it in the first place.
>
>If a previously versioned directory is left b
On Sat, Aug 24, 2013 at 2:04 PM, Stefan Sperling wrote:
> On Sat, Aug 24, 2013 at 10:22:41AM -0500, Les Mikesell wrote:
>> Don't forget that it was subversion, not the user, that created the
>> directory and abandoned it in the first place.
>
> If a previously versioned directory is left behind un
On Sat, Aug 24, 2013 at 10:22:41AM -0500, Les Mikesell wrote:
> Don't forget that it was subversion, not the user, that created the
> directory and abandoned it in the first place.
If a previously versioned directory is left behind unversioned, that
means there are unversioned (aka obstructing) no
On Sat, Aug 24, 2013 at 6:51 AM, Ryan Schmidt
wrote:
>
>>> *This* is the problem we're discussing. *This* is what Subversion should be
>>> smart enough to avoid. None of the discussion I've read thus far gives me a
>>> convincing explanation for why this should not be possible.
>>
>> You're assu
On Sat, Aug 24, 2013 at 2:48 AM, Branko Čibej wrote:
> On 24.08.2013 03:44, Ryan Schmidt wrote:
>> On Aug 23, 2013, at 13:31, Les Mikesell wrote:
>>
>>> On Fri, Aug 23, 2013 at 1:09 PM, Edwin Castro wrote:
>>>
> I can't, off the top of my head, think of a scenario where it would be
> harmf
On 24.08.2013 13:51, Ryan Schmidt wrote:
> On Aug 24, 2013, at 02:48, Branko Čibej wrote:
>> On 24.08.2013 03:44, Ryan Schmidt wrote:
>>> On Aug 23, 2013, at 13:31, Les Mikesell wrote:
I think it is the problem we've been discussing. Leaving them means
you have to keep the containing dir
On Aug 24, 2013, at 02:48, Branko Čibej wrote:
> On 24.08.2013 03:44, Ryan Schmidt wrote:
>> On Aug 23, 2013, at 13:31, Les Mikesell wrote:
>>> I think it is the problem we've been discussing. Leaving them means
>>> you have to keep the containing directory, which becomes unversioned
>>> as you sw
On 24.08.2013 03:44, Ryan Schmidt wrote:
> On Aug 23, 2013, at 13:31, Les Mikesell wrote:
>
>> On Fri, Aug 23, 2013 at 1:09 PM, Edwin Castro wrote:
>>
I can't, off the top of my head, think of a scenario where it would be
harmful to replace an unversioned directory with a versioned instan
On Aug 23, 2013, at 13:31, Les Mikesell wrote:
> On Fri, Aug 23, 2013 at 1:09 PM, Edwin Castro wrote:
>
>>> I can't, off the top of my head, think of a scenario where it would be
>>> harmful to replace an unversioned directory with a versioned instance,
>>> leaving any unversioned local files th
On Fri, Aug 23, 2013 at 1:33 PM, Andrew Reedick
wrote:
>>
>> I can't, off the top of my head, think of a scenario where it would be
>> harmful to replace an unversioned directory with a versioned instance,
>> leaving any unversioned local files that happen to be there alone.
>> Other than maybe th
> -Original Message-
> From: Les Mikesell [mailto:lesmikes...@gmail.com]
> Sent: Friday, August 23, 2013 1:34 PM
> To: Edwin Castro
> Cc: Subversion
> Subject: Re: Switching
>
>
> I can't, off the top of my head, think of a scenario where it would be
>
On Fri, Aug 23, 2013 at 1:09 PM, Edwin Castro <0ptikgh...@gmx.us> wrote:
>> I can't, off the top of my head, think of a scenario where it would be
>> harmful to replace an unversioned directory with a versioned instance,
>> leaving any unversioned local files that happen to be there alone.
>
> Lea
On 8/23/13 10:34 AM, Les Mikesell wrote:
> I can't, off the top of my head, think of a scenario where it would be
> harmful to replace an unversioned directory with a versioned instance,
> leaving any unversioned local files that happen to be there alone.
Leaving unversioned local files alone in a
On Fri, Aug 23, 2013 at 11:17 AM, Edwin Castro <0ptikgh...@gmx.us> wrote:
>>>
>> I don't buy the argument about different histories: the pre-existing
>> directory doesn't have a subversion history, so from svn's point of
>> view there is no conflict. What are the real, practical problems that
>> y
Good to know, thank you.
-Original Message-
From: Stefan Sperling [mailto:s...@elego.de]
Sent: Friday, August 23, 2013 12:50 PM
To: Edwin Castro
Cc: users@subversion.apache.org
Subject: Re: Switching
On Fri, Aug 23, 2013 at 09:24:52AM -0700, Edwin Castro wrote:
> I think the mail
On Fri, Aug 23, 2013 at 09:24:52AM -0700, Edwin Castro wrote:
> I think the mailing list has already said the *best* way to use switch
> is to have a clean working copy (clean out all ignored and unversioned
> files which is admittedly inconvenient).
This won't help right now, but cleaning out suc
On 8/23/13 7:43 AM, John Maher wrote:
> The files in question are settings files (think config files) and
> intermediate compilet generated files. The settings files can be recreated
> at any time. If they are wrong the only thing affected is the development
> environment. The other files get
h is to
delete the conflicted directory and then svn update. If your entire
working copy is "failed" then you'd need to delete the working copy and
checkout again.
I suppose you could try switching back to a branch that doesn't contain
the directory in question, clean up, and t
On 8/23/13 8:16 AM, Anders J. Munch wrote:
> Edwin Castro wrote:
>> I think the --force option is dangerous. Try it out but, in my opinion,
>> you should not use it.
> Why? Doesn't it perfectly solve the described problem?
The problem with --force, as the documentation points out, is that it
can m
Edwin Castro wrote:
> I think the --force option is dangerous. Try it out but, in my opinion,
> you should not use it.
Why? Doesn't it perfectly solve the described problem?
I had like so many others given up on switch, because cleaning up
working copies prior to the switch was annoying busywork,
ersioned, incoming add upon
switch" which is the result of a switch. The revert command fails to bring my
working copy back to its unconflicted state. Switching back also fails.
The question is can I bring back my working directory from a failed switch (I'm
talking undo, not reso
On 8/22/13 3:00 PM, Les Mikesell wrote:
>> Why can svn not, instead, simply interpret an already existing directory
>> > as not a conflict? Certainly if a versioned file would overwrite an
>> > unversioned file of the same name then that is a true conflict because
>> > the content may differ. A dir
On Thu, Aug 22, 2013 at 4:49 PM, Travis Brown wrote:
> On Thu, Aug 22, 2013 at 04:16:49PM -0500, Les Mikesell claimed:
>
>>The contents of the file are irrelevant. The point is that it has to
>>either be versioned so svn can delete it knowing that you can get it
>>back, and then delete the conta
you have to delete it yourself. Pick one. If it really is
Why must svn delete the directory in order to create it?
Reading this thread it seems to me that the core of the issue is that svn
switch is not symmetrical when dealing with directories. When switching
away from a branch with an extra dir
On Thu, Aug 22, 2013 at 1:34 PM, John Maher wrote:
> Again Les, you misunderstand. I have no problems with the workspace. It is
> exactly the same for everyone, everytime. Please read carefully before you
> respond. It has nothing to do with the build. It is user settings, a config
> file,
> irrelevant ramblings. Should quit while you're ahead.
>
> -Original Message-
> From: Edwin Castro [mailto:0ptikgh...@gmx.us]
> Sent: Thursday, August 22, 2013 2:30 PM
> To: users@subversion.apache.org
> Subject: Re: Switching
>
> On 8/22/13 10:54 AM, John Maher
On Aug 22, 2013, at 13:39, John Maher wrote:
> You digress. Not a single one of the compiled libraries lives within the
> versioned directories. Please read the question before replying incorrectly.
> It has nothing to do with code. It has nothing to do with the build.
> Please ask for c
suggestion
with the force option. Then you wandered off to completely irrelevant
ramblings. Should quit while you're ahead.
-Original Message-
From: Edwin Castro [mailto:0ptikgh...@gmx.us]
Sent: Thursday, August 22, 2013 2:30 PM
To: users@subversion.apache.org
Subject: Re: Swit
x27;t understand please ask
for clarification instead of making incorrect assumptions.
-Original Message-
From: Les Mikesell [mailto:lesmikes...@gmail.com]
Sent: Thursday, August 22, 2013 2:28 PM
To: John Maher
Cc: Edwin Castro; users@subversion.apache.org
Subject: Re: Switching
On Thu, Aug 22, 20
On 8/22/13 10:54 AM, John Maher wrote:
> This happens even if you do not do a build. There is a class library in one
> branch but not the other mixed with unversioned files that I can do nothing
> about.
Statements like this make me believe that build system is broken. I
would expect the svn sw
On Thu, Aug 22, 2013 at 12:58 PM, John Maher wrote:
> You are correct that there will be issues with a fresh checkout. But I can
> live with that.
Not caring if you can reproduce a workspace is a bold statement to
make on a version control mail list. Don't be surprised if everyone
doesn't agre
oices others have made by
> versioning it.
>
> Think config or settings file.
>
> -Original Message-
> From: Les Mikesell [mailto:lesmikes...@gmail.com]
> Sent: Thursday, August 22, 2013 1:53 PM
> To: John Maher
> Cc: Edwin Castro; users@subversion.apache.org
&
On Thu, Aug 22, 2013 at 12:52 PM, John Maher wrote:
> I'll try to clarify, everyone has their own copy of the tool. They also have
> their own copy of their settings. The problem arises because the tool stores
> the settings files in the same folder as some code specific files. This can
> no
versioning
it.
Think config or settings file.
-Original Message-
From: Les Mikesell [mailto:lesmikes...@gmail.com]
Sent: Thursday, August 22, 2013 1:53 PM
To: John Maher
Cc: Edwin Castro; users@subversion.apache.org
Subject: Re: Switching
On Thu, Aug 22, 2013 at 12:43 PM, John Maher
nversioned file
Switch can't remove wc/X because wc/X/f exists:
svn sw ^/A wc
svn st wc
? wc/X
The unversioned wc/X will cause a conflict when switching back:
svn sw ^/B wc --accept postpone
svn st wc
D C wc/X
> local dir unversioned, incoming dir add upon switch
Maher; Johan Corveleyn
Cc: Thorsten Schöning; users@subversion.apache.org
Subject: RE: Switching
> -Original Message-
> From: John Maher [mailto:jo...@rotair.com]
> Sent: Thursday, August 22, 2013 1:34 PM
> To: Johan Corveleyn
> Cc: Thorsten Schöning; users@subversion.apach
on
unversioned files being in a workspace at all, much less for them to
continue to exist when switching among versions with/without the
containing directories. I'd advise stepping back from the immediate
problem and thinking of processes that will always work with a fresh
checkout so
22, 2013 1:30 PM
To: John Maher
Cc: Thorsten Schöning; users@subversion.apache.org
Subject: Re: Switching
On Thu, Aug 22, 2013 at 12:15 PM, John Maher wrote:
> "How about just 'delete the spurious unversioned files yourself'?"
>
> As I said in the previous reply, two
> -Original Message-
> From: John Maher [mailto:jo...@rotair.com]
> Sent: Thursday, August 22, 2013 1:34 PM
> To: Johan Corveleyn
> Cc: Thorsten Schöning; users@subversion.apache.org
> Subject: RE: Switching
>
>
> The problem isn't something in the
-
From: Edwin Castro [mailto:0ptikgh...@gmx.us]
Sent: Thursday, August 22, 2013 1:22 PM
To: users@subversion.apache.org
Subject: Re: Switching
On 8/22/13 7:59 AM, Les Mikesell wrote:
> On Thu, Aug 22, 2013 at 6:30 AM, John Maher wrote:
>> >
>> > @Andrew there is no need for a s
e branch but not the other.
Subversion half empties it when switching to the branch without the directory.
Then when switching back to the branch where the directory lives it complains
that it can not add it because it is there. But that very same directory was
part of the branch that is complai
On Thu, Aug 22, 2013 at 12:15 PM, John Maher wrote:
> "How about just 'delete the spurious unversioned files yourself'?"
>
> As I said in the previous reply, two of those files are user settings. They
> would have to be constantly recreated by the developer. That increases
> costs. One of the
On 8/22/13 7:59 AM, Les Mikesell wrote:
> On Thu, Aug 22, 2013 at 6:30 AM, John Maher wrote:
>> >
>> > @Andrew there is no need for a svn copy. I do not want to copy a feature
>> > in one branch to another; I wish to keep the code isolated.
>> >
>> > And yes I know subversion won't delete unvers
nt: Thursday, August 22, 2013 1:11 PM
To: John Maher
Cc: Thorsten Schöning; users@subversion.apache.org
Subject: Re: Switching
On Thu, Aug 22, 2013 at 11:40 AM, John Maher wrote:
> I don't think you even tried Thorsten,
>
> I can easily. There are actually several options.
How abou
n tried Thorsten,
>
> I can easily. There are actually several options.
>
> 1) When switching branches don't raise a conflict if all the files in the
> directory are in the global ignore list. And if all that exists in a
> directory are files to be ignored it makes logica
On Thu, Aug 22, 2013 at 11:40 AM, John Maher wrote:
> I don't think you even tried Thorsten,
>
> I can easily. There are actually several options.
How about just 'delete the spurious unversioned files yourself'? The
problem is the versioned directory containing them that is not
supposed to exi
> > -Original Message-
> > From: Thorsten Schöning [mailto:tschoen...@am-soft.de]
> > Sent: Thursday, August 22, 2013 12:21 PM
> > To: users@subversion.apache.org
> > Subject: Re: Switching
> >
> > How would you like Subversion to work in your case
I don't think you even tried Thorsten,
I can easily. There are actually several options.
1) When switching branches don't raise a conflict if all the files in the
directory are in the global ignore list. And if all that exists in a directory
are files to be ignored it makes logica
> -Original Message-
> From: Thorsten Schöning [mailto:tschoen...@am-soft.de]
> Sent: Thursday, August 22, 2013 12:21 PM
> To: users@subversion.apache.org
> Subject: Re: Switching
>
> How would you like Subversion to work in your case? From my
> understanding it
Guten Tag John Maher,
am Donnerstag, 22. August 2013 um 17:48 schrieben Sie:
> Actually I would call the problem the way I am using the tool.
> Since no one has provided a better solution there may not be one.
> Perhaps no one considered switching between branches where there
> c
Thanks for the reply Les.
Actually I would call the problem the way I am using the tool. Since no one
has provided a better solution there may not be one. Perhaps no one considered
switching between branches where there could exist a directory with unversioned
files in one and not the other
On Thu, Aug 22, 2013 at 6:30 AM, John Maher wrote:
>
> @Andrew there is no need for a svn copy. I do not want to copy a feature in
> one branch to another; I wish to keep the code isolated.
>
> And yes I know subversion won't delete unversioned files, I appreciate the
> info on how subversion w
On Thu, Aug 22, 2013 at 1:30 PM, John Maher wrote:
> Thanks for your replies Andrew and Thorsten.
>
>
> @Andrew there is no need for a svn copy. I do not want to copy a feature in
> one branch to another; I wish to keep the code isolated.
>
> And yes I know subversion won't delete unversioned fi
7;ll check stackoverflow before I give up.
Thanks anyway
JM
-Original Message-
From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net]
Sent: Tuesday, August 20, 2013 4:02 PM
To: John Maher; Subversion help
Subject: RE: Switching
> -Original Message-
> From: John Maher [mailto:
start: You switched to branch P from
some other branch, which contained the directory and it surely did
contain unversioned files which prevented svn from deleting the
directory on switching to branch P.
> But I won't get my hopes
> up yet, I still do not have the new library included
> -Original Message-
> From: John Maher [mailto:jo...@rotair.com]
> Sent: Tuesday, August 20, 2013 1:33 PM
> To: Andrew Reedick; Subversion help
> Subject: RE: Switching
>
> Thanks for your reply. I agree it does not make sense. But it is
> reproducible
iginal Message-
From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net]
Sent: Tuesday, August 20, 2013 10:17 AM
To: John Maher; Subversion help
Subject: RE: Switching
> From: John Maher [mailto:jo...@rotair.com]
> Sent: Monday, August 19, 2013 1:31 PM
> To: Subversion help
> Subje
> From: John Maher [mailto:jo...@rotair.com]
> Sent: Monday, August 19, 2013 1:31 PM
> To: Subversion help
> Subject: Switching
>
> Hello,
>
> I want to thank all who have been helpful. I have gotten my test project to
> merge branches successfully. Now I am tryin
Hello,
I want to thank all who have been helpful. I have gotten my test project to
merge branches successfully. Now I am trying it on our production code and
wish to make sure I am not making any mistakes.
I use one folder for my source code (all branches) mainly because of vendor
requiremen
2012/5/28 Philip Martin :
> Philip Martin writes:
>
>>> 2. now locally exclude subdirectory b from update (svn update b
>>> --set-depth=exclude), which removes versioned subdirectory b from the
>>> local working copy
>>> 3. change the local svn:externals property set on a to become a
>>> directory
Philip Martin writes:
>> 2. now locally exclude subdirectory b from update (svn update b
>> --set-depth=exclude), which removes versioned subdirectory b from the
>> local working copy
>> 3. change the local svn:externals property set on a to become a
>> directory external:
>> /b b
>
> Here you ar
Sofie De Cooman writes:
> 1. checkout directory a recursively and locally apply an svn:externals
> property on it:
> /b/test.txt b/test.txt
Here you are setting svn:externals on the parent of the versioned
directory b that puts an external node inside b. It's not clear that we
ever intended to
Hi,
After upgrading my svn client from 1.6 to 1.7 I encountered the following:
Suppose an svn repository has the following layout
a/b
b/test.txt
(top directories a and b, a has a subdirectory b, top directory b
contains a file test.txt)
Now try the following steps:
1. checkout directory a r
On Friday 03 September 2010, REYNOLDS, Dylan wrote:
[locking a file and switching the WC loses the lock info for the WC]
> In my opinion, if the lock exists in the repository, under your user name,
> then why can't this information be pushed in to your working copy when you
> m
name, then
why can't this information be pushed in to your working copy when you make the
update/switch/checkout?
A check should be performed for repository locks that belong to the username
checking out (or switching) that working copy. If the usernames match then you
should get your
> -Original Message-
> From: C. Michael Pilato [mailto:cmpil...@collab.net]
> Sent: 02 February 2010 17:58
> To: Bailey, Darragh
> Cc: users@subversion.apache.org
> Subject: Re: Svnsync - switching source and mirror
> All that 'svnsync init'
Bailey, Darragh wrote:
> Looking to setup a mirror to a locally hosted svn repo, however it's
> expected that in the future the role of which repo is the mirror and
> which is the master will reverse.
>
> Reading up on svnsync, there appears to be some suggestion that something
> happens with the
Some typo's in my mail that I didn't spot the first time
> 5) Synchronise the repositories
> svnsync synchronize --username svnsync
> svn+ssh://svns...@remote/var/svn/mirror
>
> 6) Put the local repo into read-only mode temporarily and
> repeat step 6 (since otherwise it would read-only for
rev-change
REV="$2"
/usr/local/bin/svnsync copy-revprops --username svnsync
svn+ssh://svns...@remote/var/svn/mirror $REV &
8) Copy the repo UUID from the master to the mirror
Otherwise users can't checkout the mirror, do a svn --relocate and commit to
the master
Local system
83 matches
Mail list logo
