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:
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:
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
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
-
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, Aug 24
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
ramifications I
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
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.
In my
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-coded
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 switch away
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 directory, which
On Sat, Aug 24, 2013 at 2:48 AM, Branko Čibej br...@wandisco.com 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
harmful
On Sat, Aug 24, 2013 at 6:51 AM, Ryan Schmidt
subversion-20...@ryandesign.com 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
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)
On Sat, Aug 24, 2013 at 2:04 PM, Stefan Sperling s...@elego.de 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
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 behind
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 02:18:59PM -0500, Les Mikesell wrote:
On Sat, Aug 24, 2013 at 2:04 PM, Stefan Sperling s...@elego.de 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.
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.
If a
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
don't
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 resolve) so I can use the force option or must I always use
the force
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,
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 make
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 then switch back.
Use --force
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
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 such
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 mailing
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
you know of
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 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.
Leaving
-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
harmful to replace an unversioned directory
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 that happen
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:jo...@rotair.com]
Sent
On Thu, Aug 22, 2013 at 1:30 PM, John Maher jo...@rotair.com 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
On Thu, Aug 22, 2013 at 6:30 AM, John Maher jo...@rotair.com 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
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
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
could exist
-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 breaks down to something
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 logical sense
-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 breaks down to something
On Thu, Aug 22, 2013 at 11:40 AM, John Maher jo...@rotair.com 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
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 logical sense to ignore the parent
Maher
Cc: Thorsten Schöning; users@subversion.apache.org
Subject: Re: Switching
On Thu, Aug 22, 2013 at 11:40 AM, John Maher jo...@rotair.com 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
On 8/22/13 7:59 AM, Les Mikesell wrote:
On Thu, Aug 22, 2013 at 6:30 AM, John Maher jo...@rotair.com 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
On Thu, Aug 22, 2013 at 12:15 PM, John Maher jo...@rotair.com 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.
.
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 complaining that it can
[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 jo...@rotair.com wrote:
@Andrew there is no need for a svn copy. I do not want to copy
-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 way, the problem is something is
there when
: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 jo...@rotair.com wrote:
How about just 'delete the spurious unversioned files yourself'?
As I said in the previous reply, two of those files are user
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 that in the future you can use
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.apache.org
Subject: RE
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
? wc/X/f
Summary of conflicts:
Tree
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
Subject: Re: Switching
On Thu, Aug 22, 2013 at 12:43 PM, John Maher jo
On Thu, Aug 22, 2013 at 12:52 PM, John Maher jo...@rotair.com 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.
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
Subject: Re: Switching
On Thu, Aug 22, 2013 at 12:43
On Thu, Aug 22, 2013 at 12:58 PM, John Maher jo...@rotair.com 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
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
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, 2013
On Aug 22, 2013, at 13:39, John Maher jo...@rotair.com 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.
-
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 wrote:
This happens even if you do not do a build. There is a class library in one
branch but not the other
On Thu, Aug 22, 2013 at 1:34 PM, John Maher jo...@rotair.com 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
to delete it yourself. Pick one. If it really is
snip
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 directory
On Thu, Aug 22, 2013 at 4:49 PM, Travis Brown trav...@travisbrown.ca wrote:
On Thu, Aug 22, 2013 at 04:16:49PM -0500, Les Mikesell claimed:
snip
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
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 directory has
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 trying it on our production code and
wish
[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
Subject: Switching
Hello,
I want to thank all who have been
-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. The dir trees are NOT identical
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 which was the
whole reason for creating the branch in the first place. So I copy
over the directory and do a svn add then commit. Then I can
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
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
Sofie De Cooman s...@sofiedc.be 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
Philip Martin philip.mar...@wandisco.com 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
2012/5/28 Philip Martin phi...@codematters.co.uk:
Philip Martin philip.mar...@wandisco.com 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
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 lock, along
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
make the update/switch
and commit to
the master
Local system
svnadmin dump -r0 /var/svn/master | head -n 3 saved-uuid
Remote system
svnadmin load --force-uuid /var/svn/mirror saved-uuid
Switching the role of mirror and master
9) Set current master to read-only
i.e. Take the pre-commit and pre-rev-prop from step 3
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
77 matches
Mail list logo
