Re: Switching to a specific revision
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.pegrevs.html Thank you, Nathan. That answers my question. I did not know about peg revisions.
Re: Switching to a specific revision
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/rvr/6932/Client/B1/Addons/AddCost' path
> not found
>
> This path is indeed not present in r6932, but it exists in
> r1431. Why does SVN try to access the later revision in
> spite of being told to use 1431?
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.pegrevs.html
("Version Control With Subversion," chapter 3 "Advanced Topics,"
section "Peg and Operative Revisions")
Cheers,
Nathan
Re: Switching
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 continue with whatever operation caused the conflict in the first place. I agree the layering is somewhat complex. 'svn resolve' now contains several operations similar to update and merge, and which had to be implemented from scratch where the existing update/merge code couldn't be used without modification. The callbacks are either conflict resolution callbacks that are needed to support different client implementations at the API level, or they're the editor callbacks which give the resolution code a structure similar to the update and merge code. Technically, the editor API wouldn't be needed within 'svn resolve', as it is intended to work primarily offline. However, it may need to contact a server in the future. Also, we decided to use the new resolver as a test bed for the new EditorV2 API, which hasn't seen much use otherwise (expect in JavaHL and experimental branches). You'd probably have to add a new operation within the wc_db code first and then work your way up.
RE: Switching
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 do not even know. -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 Subject: Re: Switching 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 know what the contents of the incoming directory will be nor what the user may eventually want to do to resolve the problem. Making the unversioned directory versioned is just one possible options among several. See Branko's post: http://svn.haxx.se/users/archive-2013-08/0478.shtml I read that and I still wrote and posted the patch because the arguments there bear no relation to what _this_ patch does. That post does a fine job describing a few challenges for what a more complete system would do. This patch just makes the ratchet not cut the user's knuckles when they reverse direction, it isn't the fully automated manufacturing plant most of this thread seem to be talking about. John, before I go onto to exhaustively say my final piece on this matter, you have my patch[0] which I believe makes your use case work. If you have the resources to run an otherwise standard SVN binary with this patch applied I would consider doing it. Now I'll address Branko's points directly in a tedious fashion. You're assuming it is correct, in all cases, to silently make a directory versioned because the incoming directory happens to have the same name. It is not. It may be marginally correct in your case, however, Subversion has no way of knowing that the unversioned directory it sees is in any way related to whatever is on the switched branch. It needs user input; it cannot magically become smart enough. This thinking is much higher level and trying to do much more than this patch. This patch doesn't attempt to deal with trying to merge the existing unversioned file hierarchy and the incoming version object hierarchy. It merely avoids unnecessary tree conflicts on directories in _one_ specific case. The general problem is hard, but this is not the general problem. For example, consider a typical Java module which has build.xml file and two directories, src and test. You add such a module called A on the branch. Someone else creates a completely different and unrelated module in their working copy, incidentally also calling it A. Then they switch to the branch. What happens? You're proposing that Subversion would say, Oh, this unversioned thing I have here is also called A, I'm going to assume its the same as the incoming directory, let's make it so. And in the next step: Oh, I have an unversioned file called build.xml, I'll just assume it's the same as the incoming and merge changes in boom, instant merge conflict. This goes further than this patch attempts. This patch only says I see you have an existing directory called A. I won't make you move/delete it, instead I'll just continue on filling in this hierarchy as if I created this directory. Significantly, this patch doesn't change anything about how _files_ within this hierarchy are dealt with. If you have an unversioned _file_ within the directory with the same name as in incoming versioned object then you still get a tree conflict as you would in a similar situation without an incoming directory. [As an aside a merge conflict is superior in every case to a tree conflict. It would be useful if some other patch changed this case from a tree conflict to a merge conflict where svn didn't try to merge anything, but only gives you the Theirs, Mine, Edit (and equivalent) options. But that's a separate discussion.] It actually gets worse, because following your proposal, Subversion will happily recurse in the same way into src and test -- the final result being an unholy mess that you're going to have a fine time untangling, not to mention that you just messed up the poor user's unversioned local changes. As noted above this patch doesn't modify _anything_ local in any way which is not obviously reversible. The existing directory has no permissions or properties changed. No existing files are modified at all. The directory now contains files it didn't originally, but svn will tell you which files were originally there since they are either unversioned or in the conflict state. And of course, all of the above is not specific to switch -- but also to update, when there are no branches
Re: Switching
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 do not even know. Try svn help patch. But here's a fair warning: According to us devs, the patch is not the correct solution. If you apply it and it breaks some other use case, please don't complain about it on this list. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
RE: Switching
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 branch that has any new libraries. Switching away from that type of branch works fine. -Original Message- From: Travis Brown [mailto:trav...@travisbrown.ca] Sent: Monday, August 26, 2013 2:58 PM To: John Maher Cc: Subversion Subject: Re: Switching On Mon, Aug 26, 2013 at 01:31:49PM +, John Maher claimed: 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 do not even know. It's a patch you need to apply to the Subversion source code before building it. On a Unix-like system the following steps are what I do: daredevil:~/temp $ tar -jxf subversion-1.8.1.tar.bz2 daredevil:~/temp $ cd subversion-1.8.1 daredevil:#emp/subversion-1.8.1 $ patch -p1 ../local_unversioned_dir-incoming_add_dir.patch patching file subversion/libsvn_wc/update_editor.c Hunk #1 succeeded at 2249 (offset -1 lines). daredevil:#emp/subversion-1.8.1 $ You would then go ahead and build Subversion as normal for whatever platform(s) you are on. Unfortunately I cannot provide any guidance on how to accomplish this with a packaging system such as RPM or on Windows. If you don't have existing infrastructure and procedures to install and update software installed from source then this patch may be a greater maintenance 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 Subject: Re: Switching 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 know what the contents of the incoming directory will be nor what the user may eventually want to do to resolve the problem. Making the unversioned directory versioned is just one possible options among several. See Branko's post: http://svn.haxx.se/users/archive-2013-08/0478.shtml I read that and I still wrote and posted the patch because the arguments there bear no relation to what _this_ patch does. That post does a fine job describing a few challenges for what a more complete system would do. This patch just makes the ratchet not cut the user's knuckles when they reverse direction, it isn't the fully automated manufacturing plant most of this thread seem to be talking about. John, before I go onto to exhaustively say my final piece on this matter, you have my patch[0] which I believe makes your use case work. If you have the resources to run an otherwise standard SVN binary with this patch applied I would consider doing it. Now I'll address Branko's points directly in a tedious fashion. You're assuming it is correct, in all cases, to silently make a directory versioned because the incoming directory happens to have the same name. It is not. It may be marginally correct in your case, however, Subversion has no way of knowing that the unversioned directory it sees is in any way related to whatever is on the switched branch. It needs user input; it cannot magically become smart enough. This thinking is much higher level and trying to do much more than this patch. This patch doesn't attempt to deal with trying to merge the existing unversioned file hierarchy and the incoming version object hierarchy. It merely avoids unnecessary tree conflicts on directories in _one_ specific case. The general problem is hard, but this is not the general problem. For example, consider a typical Java module which has build.xml file and two directories, src and test. You add such a module called A on the branch. Someone else creates a completely different and unrelated module in their working copy, incidentally also calling it A. Then they switch to the branch. What happens? You're proposing that Subversion would say, Oh, this unversioned thing I have here is also called A, I'm going to assume its the same as the incoming directory, let's make it so. And in the next step: Oh, I have an unversioned file called build.xml, I'll just assume it's the same as the incoming and merge changes in boom, instant merge conflict. This goes further than this patch attempts. This patch only says I see you have an existing directory called A. I won't make you move/delete it, instead I'll just continue on filling
Re: 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 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 user may eventually want to do to resolve the problem. Making the unversioned directory versioned is just one possible options among several. See Branko's post: http://svn.haxx.se/users/archive-2013-08/0478.shtml I read that and I still wrote and posted the patch because the arguments there bear no relation to what _this_ patch does. That post does a fine job describing a few challenges for what a more complete system would do. This patch just makes the ratchet not cut the user's knuckles when they reverse direction, it isn't the fully automated manufacturing plant most of this thread seem to be talking about. 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 conflict resolution choices on several occasions (see, for example, http://svn.apache.org/r1161219). Those changes got shot down during peer review, because there were cases where the hard-coded behaviour was problematic. More importantly, intertwining conflict resolution with the update/merge logic tends to make the code overly complicated and fragile once we look past trivial conflict cases. So our current approach is to always flag conflicts during update and merge, and then let 'svn resolve' deal with these conflicts in a separate step. I would consider your patch if it made 'svn resolve' deal with the tree conflict raised on the obstructing directory, rather than changing how 'svn switch' behaves now. We've spent a lot of time on detecting tree conflicts, and in 1.8 we've also started to improve the interactive menu for tree conflicts involving local moves. I'd like to see further improvements there, even if it's harder than patching up a few use cases. I think we'll get a more flexible and reliable system in the long term this way.
Re: Switching
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 conflict resolution choices on several occasions (see, for example, http://svn.apache.org/r1161219). Those changes got shot down during peer review, because there were cases where the hard-coded behaviour was problematic. More importantly, intertwining conflict resolution with the update/merge logic tends to make the code overly complicated and fragile once we look past trivial conflict cases. So our current approach is to always flag conflicts during update and merge, and then let 'svn resolve' deal with these conflicts in a separate step. I would consider your patch if it made 'svn resolve' deal with the tree conflict raised on the obstructing directory, rather than changing how 'svn switch' behaves now. We've spent a lot of time on detecting tree conflicts, and in 1.8 we've also started to improve the interactive menu for tree conflicts involving local moves. I'd like to see further improvements there, even if it's harder than patching up a few use cases. I think we'll get a more flexible and reliable system in the long term this way. It's nice to finally see a concrete, technical objection. 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 continue with whatever operation caused the conflict in the first place. This isn't my itch so I'm uninterested in spending any more time than I have already investigating it. IMHO any solution to this problem which requires any further user input, whether a manual conflict resolution or running a second command, is a waste of time. What I saw in my brief look indicates that it'll be a significant effort to accomplish this level of polish with the existing code structure. Since my patch has legitimate objections and I'm not willing to implement the supported alternative I'll let this drop now. -- Travis pgppyJotpyfho.pgp Description: PGP signature
Re: Switching
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 from the branch having it, Correct. and then a conflict when you switch back. *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 assuming it is correct, in all cases, to silently make a directory versioned because the incoming directory happens to have the same name. It is not. It may be marginally correct in your case, however, Subversion has no way of knowing that the unversioned directory it sees is in any way related to whatever is on the switched branch. It needs user input; it cannot magically become smart enough. If, as you said below, this shouldn't happen generally, then one way to make Subversion smart enough would be to have it remember when it converted a directory from versioned to unversioned due to a switch, so that it can then seamlessly transform it back if the user switches back. For example, consider a typical Java module which has build.xml file and two directories, src and test. You add such a module called A on the branch. Someone else creates a completely different and unrelated module in their working copy, incidentally also calling it A. Then they switch to the branch. What happens? You're proposing that Subversion would say, Oh, this unversioned thing I have here is also called A, I'm going to assume its the same as the incoming directory, let's make it so. And in the next step: Oh, I have an unversioned file called build.xml, I'll just assume it's the same as the incoming and merge changes in boom, instant merge conflict. Certainly if there are *file* conflicts then Subversion should complain loudly and not do anything automatically, however that was not the scenario the person who opened this thread posed.
Re: Switching
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 becomes unversioned as you switch away from the branch having it, Correct. and then a conflict when you switch back. *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 assuming it is correct, in all cases, to silently make a directory versioned because the incoming directory happens to have the same name. It is not. It may be marginally correct in your case, however, Subversion has no way of knowing that the unversioned directory it sees is in any way related to whatever is on the switched branch. It needs user input; it cannot magically become smart enough. If, as you said below, this shouldn't happen generally, then one way to make Subversion smart enough would be to have it remember when it converted a directory from versioned to unversioned due to a switch, so that it can then seamlessly transform it back if the user switches back. Because a) that would mean the working copy would have to remember /all/ opereations that ever happend in its history, and b) it wouldn't work anyway because even if we did a), there's still no way for the working copy to know what happened outside of Subversion. And you're ignoring the update case, which breaks your solution. We surely have better things to do than invest man-years of time into fixing a problem that goes away if you actually take the time to read documentation. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Switching
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 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 directory is not the problem. 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 from the branch having it, Correct. and then a conflict when you switch back. *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 assuming it is correct, in all cases, to silently make a directory versioned because the incoming directory happens to have the same name. It is not. It may be marginally correct in your case, however, Subversion has no way of knowing that the unversioned directory it sees is in any way related to whatever is on the switched branch. It needs user input; it cannot magically become smart enough. For example, consider a typical Java module which has build.xml file and two directories, src and test. You add such a module called A on the branch. Someone else creates a completely different and unrelated module in their working copy, incidentally also calling it A. Then they switch to the branch. What happens? You're proposing that Subversion would say, Oh, this unversioned thing I have here is also called A, I'm going to assume its the same as the incoming directory, let's make it so. And in the next step: Oh, I have an unversioned file called build.xml, I'll just assume it's the same as the incoming and merge changes in boom, instant merge conflict. It actually gets worse, because following your proposal, Subversion will happily recurse in the same way into src and test -- the final result being an unholy mess that you're going to have a fine time untangling, not to mention that you just messed up the poor user's unversioned local changes. And of course, all of the above is not specific to switch -- but also to update, when there are no branches involved. So, yeah, it ain't gonna happen. You /do/ have the option to use --force, but there's a reason why that isn't the default. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Switching
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 possible. You're assuming it is correct, in all cases, to silently make a directory versioned because the incoming directory happens to have the same name. I'm not sure anyone proposed silently assuming anything. I'd suggest adding a way to tell it to overwrite unversioned directories and files with identical contents without also telling it to overwrite files with differing content. It is not. It may be marginally correct in your case, however, Subversion has no way of knowing that the unversioned directory it sees is in any way related to whatever is on the switched branch. It needs user input; it cannot magically become smart enough. Don't forget that it was subversion, not the user, that created the directory and abandoned it in the first place. Yes, some of the other tools the user uses may be equally dumb about leaving cruft behind and confusing svn, but the user may not know the internals of all the tools. If, as you said below, this shouldn't happen generally, then one way to make Subversion smart enough would be to have it remember when it converted a directory from versioned to unversioned due to a switch, so that it can then seamlessly transform it back if the user switches back. For example, consider a typical Java module which has build.xml file and two directories, src and test. You add such a module called A on the branch. Someone else creates a completely different and unrelated module in their working copy, incidentally also calling it A. Then they switch to the branch. What happens? You're proposing that Subversion would say, Oh, this unversioned thing I have here is also called A, I'm going to assume its the same as the incoming directory, let's make it so. And in the next step: Oh, I have an unversioned file called build.xml, I'll just assume it's the same as the incoming and merge changes in boom, instant merge conflict. Certainly if there are *file* conflicts then Subversion should complain loudly and not do anything automatically, however that was not the scenario the person who opened this thread posed. I'd propose that file conflicts aren't really conflicts if the contents are identical. And that there should be a way to tell subversion to go ahead and force overwrites of directories and identical file contents without, at the same time, telling it to clobber files with differing data. -- Les Mikesell lesmikes...@gmail.com
Re: Switching
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) nodes within the directory, such as files created during a build. Those files could not have been created by svn. 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 should interactively offer a set of reasonable courses of action, such as removing the unversioned nodes, or moving them to a special lost+found area, or something else that allows incoming versioned nodes to be created in their place.
Re: Switching
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 behind unversioned, that means there are unversioned (aka obstructing) nodes within the directory, such as files created during a build. Those files could not have been created by svn. Sure, other tools besides subversion do some unintuitive things... 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 should interactively offer a set of reasonable courses of action, such as removing the unversioned nodes, or moving them to a special lost+found area, or something else that allows incoming versioned nodes to be created in their place. Yes, but it would be nice if one of the choices were to overwrite all unversioned directories and files with identical contents (but not files with different contents) - perhaps optionally listing any unversioned non-conflicting files that happen to be there. -- Les Mikesell lesmikes...@gmail.com
Re: Switching
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 unversioned, that
means there are unversioned (aka obstructing) nodes within the
directory, such as files created during a build. Those files could
not have been created by svn.
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 should interactively offer a set of
reasonable courses of action, such as removing the unversioned nodes,
or moving them to a special lost+found area, or something else that
allows incoming versioned nodes to be created in their place.
That's just overcomplicating the issue. This doesn't even need to
become a tree conflict. There seems to be confusion about what is
actually needed to solve the OP's original problem and to make svn
switch symmetric. I've attached a simple patch which solves the issue in
the method that I proposed. I've tested it manually and it's fine, but
I haven't run it through the test suite and haven't covered the
directory permission difference case. I'm not sure it is even desirable
to check the directory permissions.
--
Travis
[[[
If an unversioned directory exists when an versioned directory of the same name
is incoming, don't create a tree conflict. Instead coopt the existing directory
and all the unversioned objects within.
* subversion/libsvn_wc/update_editor.c
(add_directory): Don't consider a pre-existing, unversioned directory a
conflict.
Patch by: Travis Brown trav...@travisbrown.ca
]]]
Index: unversioned_dir/subversion/libsvn_wc/update_editor.c
===
--- unversioned_dir.orig/subversion/libsvn_wc/update_editor.c
+++ unversioned_dir/subversion/libsvn_wc/update_editor.c
@@ -2250,7 +2250,7 @@ add_directory(const char *path,
else
db-shadowed = TRUE; /* Only update BASE */
}
- else if (kind != svn_node_none)
+ else if (kind != svn_node_none kind != svn_node_dir)
{
/* There's an unversioned node at this path. */
db-obstruction_found = TRUE;
pgpl5a2xxoNdU.pgp
Description: PGP signature
Re: Switching
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 user may eventually want to do to resolve the problem. Making the unversioned directory versioned is just one possible options among several. See Branko's post: http://svn.haxx.se/users/archive-2013-08/0478.shtml
Re: Switching
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. svn should interactively offer a set of reasonable courses of action, such as removing the unversioned nodes, or moving them to a special lost+found area, or something else that allows incoming versioned nodes to be created in their place. Yes, but it would be nice if one of the choices were to overwrite all unversioned directories and files with identical contents (but not files with different contents) - perhaps optionally listing any unversioned non-conflicting files that happen to be there. Sure. If that's an option people consider useful we can add it to a conflict menu, once it exists. I'm very open to suggestions because we really don't know what users need in many such cases.
Re: Switching
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 previously versioned directory is left behind unversioned, that means there are unversioned (aka obstructing) nodes within the directory, such as files created during a build. Those files could not have been created by svn. 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 should interactively offer a set of reasonable courses of action, such as removing the unversioned nodes, or moving them to a special lost+found area, or something else that allows incoming versioned nodes to be created in their place. That's just overcomplicating the issue. This doesn't even need to become a tree conflict. There seems to be confusion about what is actually needed to solve the OP's original problem and to make svn switch symmetric. I've attached a simple patch which solves the issue in the method that I proposed. I already explained at length why this solution is absolutely the wrong approach. It solves a small subset of cases at the cost of causing serious grief to users in the majority of cases. Let's please just stop discussing this approach because it is not viable. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Switching
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 know what the contents of the incoming directory will be nor what the user may eventually want to do to resolve the problem. Making the unversioned directory versioned is just one possible options among several. See Branko's post: http://svn.haxx.se/users/archive-2013-08/0478.shtml I read that and I still wrote and posted the patch because the arguments there bear no relation to what _this_ patch does. That post does a fine job describing a few challenges for what a more complete system would do. This patch just makes the ratchet not cut the user's knuckles when they reverse direction, it isn't the fully automated manufacturing plant most of this thread seem to be talking about. John, before I go onto to exhaustively say my final piece on this matter, you have my patch[0] which I believe makes your use case work. If you have the resources to run an otherwise standard SVN binary with this patch applied I would consider doing it. Now I'll address Branko's points directly in a tedious fashion. You're assuming it is correct, in all cases, to silently make a directory versioned because the incoming directory happens to have the same name. It is not. It may be marginally correct in your case, however, Subversion has no way of knowing that the unversioned directory it sees is in any way related to whatever is on the switched branch. It needs user input; it cannot magically become smart enough. This thinking is much higher level and trying to do much more than this patch. This patch doesn't attempt to deal with trying to merge the existing unversioned file hierarchy and the incoming version object hierarchy. It merely avoids unnecessary tree conflicts on directories in _one_ specific case. The general problem is hard, but this is not the general problem. For example, consider a typical Java module which has build.xml file and two directories, src and test. You add such a module called A on the branch. Someone else creates a completely different and unrelated module in their working copy, incidentally also calling it A. Then they switch to the branch. What happens? You're proposing that Subversion would say, Oh, this unversioned thing I have here is also called A, I'm going to assume its the same as the incoming directory, let's make it so. And in the next step: Oh, I have an unversioned file called build.xml, I'll just assume it's the same as the incoming and merge changes in boom, instant merge conflict. This goes further than this patch attempts. This patch only says I see you have an existing directory called A. I won't make you move/delete it, instead I'll just continue on filling in this hierarchy as if I created this directory. Significantly, this patch doesn't change anything about how _files_ within this hierarchy are dealt with. If you have an unversioned _file_ within the directory with the same name as in incoming versioned object then you still get a tree conflict as you would in a similar situation without an incoming directory. [As an aside a merge conflict is superior in every case to a tree conflict. It would be useful if some other patch changed this case from a tree conflict to a merge conflict where svn didn't try to merge anything, but only gives you the Theirs, Mine, Edit (and equivalent) options. But that's a separate discussion.] It actually gets worse, because following your proposal, Subversion will happily recurse in the same way into src and test -- the final result being an unholy mess that you're going to have a fine time untangling, not to mention that you just messed up the poor user's unversioned local changes. As noted above this patch doesn't modify _anything_ local in any way which is not obviously reversible. The existing directory has no permissions or properties changed. No existing files are modified at all. The directory now contains files it didn't originally, but svn will tell you which files were originally there since they are either unversioned or in the conflict state. And of course, all of the above is not specific to switch -- but also to update, when there are no branches involved. Of course the same issue where svn refuses to do the right thing exists during update. I'm pretty sure, but did not test, that my patch also covers this situation. What are the sensible user actions upon a local unversioned-incoming add tree conflict upon a _directory_ with no files within it? Delete it? Rename it to delete it later? What about a _directory_ with unversioned files within it? I suppose the user could delete the directory and all the files within it, or rename it and then move the files back later. The consensus of this list seems to be
RE: Switching
I will try to explain one more time. 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 recreated every time the code is run, plus they never get into production. So they 1) could be recreated any time at will with the versioned code files and 2) they will never be in production anyway. Don't read more than what is stated otherwise you have a chance of being wrong and wasting time. Someone was claiming the files are important which I never stated. I didn't even respond to the mail since it was erroneous and irrelevant. The real reason I responded is the force option eliminates the conflict but creates some questions. The documentation says using it will make sure unversioned obstructiong paths do not cause a failure. Could that also be written as unversioned obstructiong paths do not cause a conflict? Or is there some other kind of failure that I do not know about. The problem this fixes displays as Local unversioned, 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 resolve) so I can use the force option or must I always use the force option to be able to switch branches? Have a good weekend JM -Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Thursday, August 22, 2013 5:17 PM To: John Maher Cc: Edwin Castro; users@subversion.apache.org Subject: Re: Switching 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 config file, ini file, choose your terminology. If you don't understand please ask for clarification instead of making incorrect assumptions. 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 containing directory that is really the issue, or you have to delete it yourself. Pick one. If it really is always the same, I don't see the problem with committing it. If it isn't, and you need to reproduce it, you need to work out a way to do that, or use the multiple-checkout approach to maintain dirty workspaces, realizing that you can't reproduce them reliably. Personally, I don't like things that rely on any unversioned state getting into production releases. That developer will leave or that machine will crash and all the magic is gone - and if you can't do a matching build on a clean machine from a clean checkout, you won't ever know how much magic was involved. -- Les Mikesell lesmikes...@gmail.com
Re: Switching
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, an unnecessary risk (you might delete files that you wished you hadn't) and very easily forgotten, leading to a messed up working copy. But now I'm beginning to rethink that; I just have to remember to use --force with every svn switch. 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 or foresee with svn swich --force? regards, Anders
Re: Switching
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 things versioned that were previously unversioned. Using a concrete example, a *.sou file that was previously unversioned might become versioned after a switch and then gets committed, accidentally, into your respository. I had like so many others given up on switch, because cleaning up working copies prior to the switch was annoying busywork, an unnecessary risk (you might delete files that you wished you hadn't) and very easily forgotten, leading to a messed up working copy. But now I'm beginning to rethink that; I just have to remember to use --force with every svn switch. 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 or foresee with svn swich --force? When objects do not have history, then subversion is in the position to try to decide what to do with content that already exists on the filesystem. It can't make reasonable decisions because there is no base revision to use in the 3-way diff. Ultimately, the proper response is for subversion to say I can't add the file/directory/what-have-you because there is something blocking my way. It then becomes the user's responsibility to determine what to do. Thinking in the most general sense, one solution for this scenario might work well for one individual but not another. The prescribed solution might not even work reliably every time that one individual sees this scenario. In order for subversion to do the right thing it would need to be psychic. I'm afraid subversion already takes the best possible action which is to require user intervention. -- Edwin G. Castro
Re: Switching
On 8/23/13 7:43 AM, John Maher wrote: 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 option to be able to switch branches? 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). Some offered the opinion that the best way to use switch was to not use it at all. One way to bring back your working directory from a failed switch 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 then switch back. Use --force with caution. According to the documentation it can accidentally version previously unversioned files. -- Edwin G. Castro
Re: Switching
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 recreated every time the code is run, plus they never get into production. So they 1) could be recreated any time at will with the versioned code files and 2) they will never be in production anyway. Don't read more than what is stated otherwise you have a chance of being wrong and wasting time. When these files get in the way of subversion performing an operation, then the sensible thing to do is to delete them. I think I heard many people voice this opinion on this mailing list. If their contents should be kept around then they should be versioned. That opinion was also voiced by the mailing list. -- Edwin G. Castro
Re: Switching
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 items will be easier in Subversion 1.9: https://blog.elegosoft.com/?q=cleaning-up-svn-cleanup
RE: Switching
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 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 items will be easier in Subversion 1.9: https://blog.elegosoft.com/?q=cleaning-up-svn-cleanup
Re: Switching
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 or foresee with svn swich --force? When objects do not have history, then subversion is in the position to try to decide what to do with content that already exists on the filesystem. 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 the chance that you'd accidentally commit them later, but that is no different than if you had put the local files in after the switch. Am I missing something? Is there a way to --force that without also potentially --force'ing files that conflict to be clobbered? -- Les Mikesell lesmikes...@gmail.com
Re: Switching
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 directory is not the problem. I've personally ran into scenarios where the local directory contained unversioned local files that obstruct a file that will be added by a switch/update/merge/what-have-you. If the local file's content matches the content in the repository, then I think it is safe to simply replace the unversioned local file with the versioned file from the repository. Often, the content has not been the same. It all depends on a lot of factors such as how it became unversioned, what has happened to the file while it was unversioned, etc. Replacing the content of the local file with the content in the repository looses local data. Merging the unversioned content and the versioned content usually result in poor merges (in the best case scenario) because there is no base revision to use in the 3-way merge. I've seen merges like this get committed accidentally and cause havoc. Of course, using the unversioned local content instead of merging the content from the repository could accidentally replace the entire contents of the file and this can accidentally get committed as well. Subversion needs the user's help to figure out what to do and marks these conflicts as tree conflicts.
Re: Switching
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 unversioned local files alone in a directory is not the problem. 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 from the branch having it, and then a conflict when you switch back. I've personally ran into scenarios where the local directory contained unversioned local files that obstruct a file that will be added by a switch/update/merge/what-have-you. Don't think that's the case here. These files are supposed to be svn-ignored, so they should not have a copy in the repo. If the local file's content matches the content in the repository, then I think it is safe to simply replace the unversioned local file with the versioned file from the repository. Yes, that would be handy - and harmless - as well. Often, the content has not been the same. It all depends on a lot of factors such as how it became unversioned, what has happened to the file while it was unversioned, etc. Replacing the content of the local file with the content in the repository looses local data. Agreed, there is no reasonable way to handle this case automatically. But it shouldn't happen as long as the clutter is never committed. It is probably bad practice to default to letting cruft stay across switches since your workspace would end up different than a fresh checkout but it would be handy to have a way to force mostly-harmless operations without overwriting any differing file data. -- Les Mikesell lesmikes...@gmail.com
RE: Switching
-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 with a versioned instance, leaving any unversioned local files that happen to be there alone. Other than maybe the chance that you'd accidentally commit them later, but that is no different than if you had put the local files in after the switch. Am I missing something? Is there a way to --force that without also potentially --force'ing files that conflict to be clobbered? Dir permissions and ownership would change to that of the current user and umask and could create a security gap, but that probably falls under if you're using --force, it's on your head. How are symlinks handled by switch --force? It fails, or does it look at the target file/dir when deciding whether to replace it with a versioned object? How are hardlinks handled by switch --force? Is the hardlinked file removed and replaced with a brand new file? Or does switch --force work directly on the hardlinked file thus updating all the copies? On the windows side, would replacing a junction cause problems?
Re: Switching
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 to be there alone. Leaving unversioned local files alone in a directory is not the problem. 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 from the branch having it, Correct. and then a conflict when you switch back. *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.
RE: Switching
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 files, I appreciate the info on how subversion works. Some of it was helpful. I was hoping to hear how others may have solved the same problem. But it seems the only answer is a tedious and manual process for the simplest of enhancements. I was hoping to find what others seem to praise, but have continually come up empty handed. I'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: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 because one branch has a library that the other does not. In normal use I would expect the branches to differ. And I assure you one of the branches does not have the directory causing the trouble, I checked on the server. So the branches are different and it appears impossible to switch between them without conflicts. For example, when I switch to branch P it switches OK. An svn status on the problem directory shows it with a '?'. Then I switch to branch E and get a conflict. It says local unversioned, incoming add upon switch. The local should be unversioned, it is not part of branch P. I do not know why the directory did not get deleted during the switch. An svn status shows the directory marked for deletion. So in one instance of time I get a message of a directory that is unversioned, incoming add, marked for deletion. When removing dirs, switch will not delete local/private/unversioned files. If there is a local file in a dir tree, then all the versioned files will be removed from your workspace, but a local tree will remain with the local files still in it. That's mostly likely why you see a '?' after the switch. Ex: 1. 'this_dir' exists in current workspace as a versioned dir tree. 2. 'this_dir' does NOT exist in branch P. 3. touch this_dir/hello_world.txt 3. svn switch ^/branches/P 4. svn status: ? this_dir The only file under this_dir will be hello_world.txt. All other versioned files/dirs will have been removed. Svn revert does not do anything useful. So I then issue svn resolve -- accept working UI_Email where UI_Email is the directory causing the problems. This clears the conflict. Then I switch to branch P. Then is says local delete, incoming delete. Why it has a local delete is beyond me. That folder is part of the branch, I want it there and never issued a delete. But subversion did. So I resolve this conflict the same as the last one and switch back to branch E. You guessed it, conflict again. You shot yourself in the foot. =) The local copy of the dir prevented switch from running the add. (Switch wasn't able to pull in the versioned copy of the dir.) Then you didn't fix the dir conflict by manually running 'svn copy' yourself to pull in the dir from branch P. When you did the resolve, you told svn that the current state of the dir is correct, and since the current state of the dir was effectively deleted, you wound up telling svn to delete the file from branch P. Again, when resolving tree conflicts, you need to manually copy/add/delete/mv manipulate the tree into the correct state before resolving the tree conflict. So I resolve the conflict then commit and decide to let subversion delete the directory (I have a backup because I've lost code to subversion before). So now my code is gone. I delete the directory with supporting files. Then I switch to branch P. Success for now (I know failure is just a matter of time). You can recover the deleted versioned dirs and files via peg revisions. http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.resurrect Then I switch to branch E. No conflict. 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. Right. You deleted the dir from branch P. And you deleted the local/private files/tree as well. Thus no conflict with branch E. However, if you want to get the dir into branch E, then you should have merged from branch P to branch E (or used 'svn copy ^/branches/P/some_dir ^/branches/E/some_dir.) (But you'll need to restore the dir in branch P first via 'svn copy' and a peg revision.) So I copy over the directory and do a svn add then commit. Then I can switch to branch P. Argh
Re: Switching
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 unversioned files, I appreciate the info on how subversion works. Some of it was helpful. I was hoping to hear how others may have solved the same problem. But it seems the only answer is a tedious and manual process for the simplest of enhancements. I was hoping to find what others seem to praise, but have continually come up empty handed. I'll check stackoverflow before I give up. The problems you are seeing here are the main reason why I (and some other users on this list) try to avoid 'switch', and instead use dedicated working copies for the different branches. Like you have seen, it's just far too likely for the different 'variants' to step on each other's toes (e.g. with generated files being in the way). Another advantage of using different checkouts is that you can immediately see (from the local directory name) in which branch you're working. Leads to less incidents of the type 'oops, committed to the wrong branch'. Except for extremely large working copies, disk space is usually cheap in comparison to the wasted time when you encounter such issues. Perhaps the initial checkout of each of the working copies takes some time, but that's mostly a one-time cost (one time per branch ... so it depends a bit on how many branches or how often you branch). I suggest you try to adapt your workflow to work with separate working copies. (This does not mean that 'switch' is completely useless -- I still use it for small ad-hoc things. It depends, YMMV. If you use it in a structural way in your workflow, I think it's best to avoid too complex working copies with perhaps local modifications, especially when there's a risk of debris being left behind). -- Johan
Re: Switching
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 subversion works. Some of it was helpful. I was hoping to hear how others may have solved the same problem. Your problem is not so much that svn doesn't deleted the unversioned files, but that it can't delete the directory containing them. But it seems the only answer is a tedious and manual process for the simplest of enhancements. Don't your build tools have commands to remove any spurious files they've created or some equivalent of 'make clean' that you can run to remove the clutter in a non-tedious way so that svn switch is free to work correctly with the versioned content? I was hoping to find what others seem to praise, but have continually come up empty handed. I'll check stackoverflow before I give up. If the big picture is including library components and their containing directories in some versions and not others, the simple solution might be to give the components their own location in the repository (or a different one) and pull them in only as needed with svn externals. But, I think you still have to clean up the unversioned clutter so a switch can remove the directory when it is not wanted. A slightly different approach is to version the built component binaries and access them with externals, but that has its own issues in multi-platform scenarios. -- Les Mikesell lesmikes...@gmail.com
RE: Switching
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. I don't know. Maybe no one wanted to make it work since they never needed that feature. I don't know. After reading tons of material on subversion I thought it would be good to keep development for individual features in separate branches. But the cost is easily out weighing the benefit. And one of the files I am ignoring is user settings which is required for testing. Deleting that file would just introduce more trouble causing the user to repeatedly re-enter settings to test code. The output is already directed away to a development directory. I see no way to delete the intermediate files which would get constantly re-created anyway and would not solve the problem because the user settings file would still cause the same issue. And the developers need their own settings. Before I started trying to learn the branching (which I didn't even get to yet since simply switching is causing so much grief) I would jot down on a piece of paper which projects affected which feature and do all the development in the trunk then only put in production what was needed. This worked. It just seems strange to have to keep notes on a piece of paper which modules are for which feature using source code control software. But if that's how subversion works, then that's how it works. -Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Thursday, August 22, 2013 11:00 AM To: John Maher Cc: Andrew Reedick; Thorsten Schöning; Subversion help Subject: Re: Switching 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 subversion works. Some of it was helpful. I was hoping to hear how others may have solved the same problem. Your problem is not so much that svn doesn't deleted the unversioned files, but that it can't delete the directory containing them. But it seems the only answer is a tedious and manual process for the simplest of enhancements. Don't your build tools have commands to remove any spurious files they've created or some equivalent of 'make clean' that you can run to remove the clutter in a non-tedious way so that svn switch is free to work correctly with the versioned content? I was hoping to find what others seem to praise, but have continually come up empty handed. I'll check stackoverflow before I give up. If the big picture is including library components and their containing directories in some versions and not others, the simple solution might be to give the components their own location in the repository (or a different one) and pull them in only as needed with svn externals. But, I think you still have to clean up the unversioned clutter so a switch can remove the directory when it is not wanted. A slightly different approach is to version the built component binaries and access them with externals, but that has its own issues in multi-platform scenarios. -- Les Mikesell lesmikes...@gmail.com
Re: Switching
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 a directory with unversioned files in one and not the other. I don't know. Maybe no one wanted to make it work since they never needed that feature. I don't know. After reading tons of material on subversion I thought it would be good to keep development for individual features in separate branches. But the cost is easily out weighing the benefit. How would you like Subversion to work in your case? From my understanding it breaks down to something generated some files for some reason in one of your branches and now you want to switch form that branch to another which does not contain the base directory of the generated files. What should subversion do with your generated files it doesn't know anything about? I don't see how this problem can be solved by any tool. 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: Switching
-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 generated some files for some reason in one of your branches and now you want to switch form that branch to another which does not contain the base directory of the generated files. What should subversion do with your generated files it doesn't know anything about? I don't see how this problem can be solved by any tool. Part of his frustration is that the files in question are listed in the global-ignores. So... maybe a feature request to have a 'svn switch' option to take global-ignores into consideration when deciding whether to keep or delete local files?
RE: Switching
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 to ignore the parent directory. 2) A parameter could be passed to the switch command to ignore any directory that ends up with only files on the global ignores list. 3) An OK-to-delete-if-in-conflict property could be created. And I don't even know the tool well, if I knew it better I can come up with even better solutions. I'm not going to bother listing any more alternatives, there are plenty. Might as well wish I had a candy bar right now. Its OK to wish, but it won't happen. I'll bet any talented developer could come up with a solution if they tried. -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 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 a directory with unversioned files in one and not the other. I don't know. Maybe no one wanted to make it work since they never needed that feature. I don't know. After reading tons of material on subversion I thought it would be good to keep development for individual features in separate branches. But the cost is easily out weighing the benefit. How would you like Subversion to work in your case? From my understanding it breaks down to something generated some files for some reason in one of your branches and now you want to switch form that branch to another which does not contain the base directory of the generated files. What should subversion do with your generated files it doesn't know anything about? I don't see how this problem can be solved by any tool. 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: Switching
-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 generated some files for some reason in one of your branches and now you want to switch form that branch to another which does not contain the base directory of the generated files. What should subversion do with your generated files it doesn't know anything about? I don't see how this problem can be solved by any tool. Part of his frustration is that the files in question are listed in the global- ignores. So... maybe a feature request to have a 'svn switch' option to take global-ignores into consideration when deciding whether to keep or delete local files? I thought svn's policy was do no harm... so un-versioned files are never deleted by default. BOb
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 yourself'? The problem is the versioned directory containing them that is not supposed to exist after the switch. And the only way svn can fix it for you is if you clean it up. Svn can't decide which of your files that it can't recreate for you should disappear. Getting that wrong would be much worse than presenting a conflict on the directory holding them. -- Les Mikesell lesmikes...@gmail.com
Re: Switching
On Thu, Aug 22, 2013 at 5:48 PM, John Maher jo...@rotair.com wrote: 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. ... Did you read my previous mail in this thread? IMO a better solution in your case is not to use switch, but use dedicated checkouts for each branch. If you have to do this often (say multiple times a day), perhaps create a small script that takes away some of the typing of 'svn co $URL/branches/X' On Thu, Aug 22, 2013 at 6:40 PM, John Maher jo...@rotair.com wrote: 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 to ignore the parent directory. What do you mean with ignore? By switching you asked Subversion to download all the data that's meant to be there. If an unversioned directory is in the way, Subversion has no place where to put that data. Do you mean SVN should just throw away your unversioned data? That would go against one of SVN's prime directives, which is to try never to destroy any unversioned data. Those unversioned files may be very important to me (even if in the global-ignores list). 2) A parameter could be passed to the switch command to ignore any directory that ends up with only files on the global ignores list. 3) An OK-to-delete-if-in-conflict property could be created. That might be possible (but this sounds *very* handwavy -- there are a lot of details in there, lots of edge cases), but that's a very dangerous flag, which makes it very much possible for people to shoot themselves in the foot. After implementing such a feature, I bet there will be more posts than yours, from people asking if they can get their data back. And I don't even know the tool well, if I knew it better I can come up with even better solutions. I'm not going to bother listing any more alternatives, there are plenty. Might as well wish I had a candy bar right now. Its OK to wish, but it won't happen. I'll bet any talented developer could come up with a solution if they tried. Perhaps, but I can't (or at least, it would take me quite a bit of my rare free time). Perhaps someone else will jump in, but if you badly want this, I think you'll have to try describing a good (detailed) behavior yourself (and be prepared to patiently answer tough questions that may arise). -- Johan
RE: Switching
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 reasons I wanted some form of source code control was to reduce costs. Svn can't decide which of your files that it can't recreate for you should disappear. It could ignore files that it is instructed to ignore. That would help. -Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: 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 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 supposed to exist after the switch. And the only way svn can fix it for you is if you clean it up. Svn can't decide which of your files that it can't recreate for you should disappear. Getting that wrong would be much worse than presenting a conflict on the directory holding them. -- Les Mikesell lesmikes...@gmail.com
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 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 works. Some of it was helpful. I was hoping to
hear how others may have solved the same problem.
Your problem is not so much that svn doesn't deleted the unversioned
files, but that it can't delete the directory containing them.
But it seems the only answer is a tedious and manual process for the
simplest of enhancements.
Don't your build tools have commands to remove any spurious files
they've created or some equivalent of 'make clean' that you can run to
remove the clutter in a non-tedious way so that svn switch is free to
work correctly with the versioned content?
I typically run into this problem when a build output directory exists
due to having built the project that doesn't exist in the other branch.
Something along these lines:
root/
+-- projectA/
| +-- bin/
| | +-- debug/
| | | +-- projectA.dll
| | +-- release/
| | +-- projectA.dll
| +-- src/
+-- projectB/
+-- bin/
| +-- debug/
| | +-- projectB.dll
| +-- release/
| +-- projectB.dll
+-- src/
Let's say in branch1 both projects exist but in branch2 only projectB
exists. The tree above would obviously imply I am currently on branch1.
I would have added the bin directory to svn:ignore on both the projectA
and projectB directories as I don't want to accidentally commit the
contents of the bin directory. The tree above is only an example. The
branches I'm used to dealing with contain hundreds of such projects and
building all of them can take up to 2 hours even on relatively fast
hardware.
If projectA has been built while I'm working on branch1 and I want to
svn switch to branch2, then svn will attempt to delete root/projectA/
but it can't because root/projectA/bin/ still exists. The switch leaves
behind root/projectA/ as unversioned (including the root/projectA/bin/
directory). Now that I'm done working with branch2 I try to svn switch
back to branch1 and svn fails to add root/projectA/ because it already
exists in the working copy unversioned.
We have a root build script that can run the clean target on all of our
projects. Alternatively, I could run clean on individual projects prior
to a switch but that requires that I know which projects do not exist on
the target branch. I could also use the --force argument to svn switch
but it carries it's own hazards. From svn help switch:
If --force is used, unversioned obstructing paths in the working
copy do not automatically cause a failure if the switch attempts to
add the same path. If the obstructing path is the same type (file
or directory) as the corresponding path in the repository it becomes
versioned but its contents are left 'as-is' in the working copy.
This means that an obstructing directory's unversioned children may
also obstruct and become versioned. For files, any content differences
between the obstruction and the repository are treated like a local
modification to the working copy. All properties from the repository
are applied to the obstructing path.
I'm particularly worried by This means that an obstructing directory's
unversioned children may also obstruct and become versioned. You might
end up committing files you don't want to commit by using svn switch
--force so you'll want to be very careful. It would probably be a good
idea to follow up svn switch --force with svn status to see if anything
becomes versioned that shouldn't be.
Even though our builds can be quite long, I typically find it much safer
to simply clean all of the projects prior to performing svn switch. I
typically don't use our root build script to clean the projects because
it takes a long time loading up all of those different
projects/solutions to run the clean target. Since I'm on Windows I use
PowerShell to find all ignored and unversioned items and manually delete
them:
svn status --no-ignore --ignore-externals | Where-Object { $_ -match
'^[I?]' } | Remove-Item -Force -Recurse -Path { $_.Substring(8) } -Verbose
I've needed to update the substring index in the past because a new svn
release changed the svn status format on me.
Performing this kind of cleanup allowed svn switch to work correctly
every time. Then again, this does imply that every thing must be rebuilt
post switch which can be very painful when you have as many projects as
we do. If some of the ignored/unversioned files are user files that
should not be versioned, then cleaning like this creates additional
problems. We've worked around these problems by requiring that user
files are not used and adding a target to our root build script which
can fetch build
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 settings. They would have to be constantly recreated by the developer. That increases costs. One of the reasons I wanted some form of source code control was to reduce costs. So put them somewhere else or version them - and if the tool can't deal with multiple users, work out a way to script a rename the correct copy for the current user. A clever developer should be able to find an alternative to forcing subversion to keep a versioned directory in conflicting place or retyping a file to recreate it when needed... Of course if it is too much trouble to clean up the files correctly, you can just delete the whole workspace and check out again to go between the branch/trunk versions. Svn can't decide which of your files that it can't recreate for you should disappear. It could ignore files that it is instructed to ignore. That would help. How many people actually know which files subversion is ignoring? Again, a clever developer could probably come up with his own way to delete files matching some patterns if he really wants that to happen. -- Les Mikesell lesmikes...@gmail.com
RE: Switching
Thanks for the reply Johan. I did not get your previous mail, thanks for re-stating it. That is worth looking into. I'll see how much I have to change to allow the alternate directories. Maybe experiment keeping the trunk on the network for backup purposes and the branches local so as not to tax the backup. The costs can really increase. If an unversioned directory is in the way, Subversion has no place where to put that data. The problem isn't something in the way, the problem is something is there when nothing is expected. There is a directory in one 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 complaining that it can not add it because it is there. What I mean by ignore is that subversion properly ignored deleting the directory because it had unversioned files in it. But refused to ignore adding it. There may be a good reason for that behavior, I just find it hard to believe that I am the only one who had this problem. I'm betting that there is some unintuitive solution to this. JM -Original Message- From: Johan Corveleyn [mailto:jcor...@gmail.com] Sent: Thursday, August 22, 2013 1:13 PM To: John Maher Cc: Thorsten Schöning; users@subversion.apache.org Subject: Re: Switching On Thu, Aug 22, 2013 at 5:48 PM, John Maher jo...@rotair.com wrote: 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. ... Did you read my previous mail in this thread? IMO a better solution in your case is not to use switch, but use dedicated checkouts for each branch. If you have to do this often (say multiple times a day), perhaps create a small script that takes away some of the typing of 'svn co $URL/branches/X' On Thu, Aug 22, 2013 at 6:40 PM, John Maher jo...@rotair.com wrote: 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 to ignore the parent directory. What do you mean with ignore? By switching you asked Subversion to download all the data that's meant to be there. If an unversioned directory is in the way, Subversion has no place where to put that data. Do you mean SVN should just throw away your unversioned data? That would go against one of SVN's prime directives, which is to try never to destroy any unversioned data. Those unversioned files may be very important to me (even if in the global-ignores list). 2) A parameter could be passed to the switch command to ignore any directory that ends up with only files on the global ignores list. 3) An OK-to-delete-if-in-conflict property could be created. That might be possible (but this sounds *very* handwavy -- there are a lot of details in there, lots of edge cases), but that's a very dangerous flag, which makes it very much possible for people to shoot themselves in the foot. After implementing such a feature, I bet there will be more posts than yours, from people asking if they can get their data back. And I don't even know the tool well, if I knew it better I can come up with even better solutions. I'm not going to bother listing any more alternatives, there are plenty. Might as well wish I had a candy bar right now. Its OK to wish, but it won't happen. I'll bet any talented developer could come up with a solution if they tried. Perhaps, but I can't (or at least, it would take me quite a bit of my rare free time). Perhaps someone else will jump in, but if you badly want this, I think you'll have to try describing a good (detailed) behavior yourself (and be prepared to patiently answer tough questions that may arise). -- Johan
RE: Switching
Thanks for the reply Edwin. The clean up script is a good idea but won't work here. We have mostly all class libraries. One executable. This means to test we need to specify an application in the project. Some developers use the exe while some use a tool made just for testing the classes. This information is in the *.sou files which are unversioned for this reason. So we don't want to delete them (as I incorrectly stated somewhere) but ignore them. I'll try the force, that may work. I'll try it on a copy of the repository. JM -Original Message- 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 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 subversion works. Some of it was helpful. I was hoping to hear how others may have solved the same problem. Your problem is not so much that svn doesn't deleted the unversioned files, but that it can't delete the directory containing them. But it seems the only answer is a tedious and manual process for the simplest of enhancements. Don't your build tools have commands to remove any spurious files they've created or some equivalent of 'make clean' that you can run to remove the clutter in a non-tedious way so that svn switch is free to work correctly with the versioned content? I typically run into this problem when a build output directory exists due to having built the project that doesn't exist in the other branch. Something along these lines: root/ +-- projectA/ | +-- bin/ | | +-- debug/ | | | +-- projectA.dll | | +-- release/ | | +-- projectA.dll | +-- src/ +-- projectB/ +-- bin/ | +-- debug/ | | +-- projectB.dll | +-- release/ | +-- projectB.dll +-- src/ Let's say in branch1 both projects exist but in branch2 only projectB exists. The tree above would obviously imply I am currently on branch1. I would have added the bin directory to svn:ignore on both the projectA and projectB directories as I don't want to accidentally commit the contents of the bin directory. The tree above is only an example. The branches I'm used to dealing with contain hundreds of such projects and building all of them can take up to 2 hours even on relatively fast hardware. If projectA has been built while I'm working on branch1 and I want to svn switch to branch2, then svn will attempt to delete root/projectA/ but it can't because root/projectA/bin/ still exists. The switch leaves behind root/projectA/ as unversioned (including the root/projectA/bin/ directory). Now that I'm done working with branch2 I try to svn switch back to branch1 and svn fails to add root/projectA/ because it already exists in the working copy unversioned. We have a root build script that can run the clean target on all of our projects. Alternatively, I could run clean on individual projects prior to a switch but that requires that I know which projects do not exist on the target branch. I could also use the --force argument to svn switch but it carries it's own hazards. From svn help switch: If --force is used, unversioned obstructing paths in the working copy do not automatically cause a failure if the switch attempts to add the same path. If the obstructing path is the same type (file or directory) as the corresponding path in the repository it becomes versioned but its contents are left 'as-is' in the working copy. This means that an obstructing directory's unversioned children may also obstruct and become versioned. For files, any content differences between the obstruction and the repository are treated like a local modification to the working copy. All properties from the repository are applied to the obstructing path. I'm particularly worried by This means that an obstructing directory's unversioned children may also obstruct and become versioned. You might end up committing files you don't want to commit by using svn switch --force so you'll want to be very careful. It would probably be a good idea to follow up svn switch --force with svn status to see if anything becomes versioned that shouldn't be. Even though our builds can be quite long, I typically find it much safer to simply clean all of the projects prior to performing svn switch. I typically don't use our root build script to clean the projects because it takes a long time loading up all of those different projects/solutions to run the clean target. Since I'm on Windows I use PowerShell to find all ignored and unversioned items and manually delete them: svn status
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: Switching The problem isn't something in the way, the problem is something is there when nothing is expected. There is a directory in one 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 complaining that it can not add it because it is there. Okay, this isn't a svn issue. This sounds more like a I did a build against trunk, switched to branch B, and then did a build of B in a dirty workspace. That's just asking for trouble in terms of build accuracy and build repeatability; it's a bad practice in general. The whole trunk, switch to B, switch back to trunk directory conflict may be an annoyance, but a 'make clean' build option or cleanup script run after the switch sounds like something that you need to implement.
RE: Switching
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 not be changed. So within a single directory we need to version some files and ignore others. Sure I could write a pre-processing program to do a multitude of things. It wouldn't be that hard. But then my plate has plenty of things that are not that hard. What will I gain? A happy working copy with a single command as long as what I write always works perfectly. Highly unlikely, so then I will make more problems for myself. Plus I assigned myself the task of learning subversion. Covering up a symptom does not treat the disease. -Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Thursday, August 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 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. One of the reasons I wanted some form of source code control was to reduce costs. So put them somewhere else or version them - and if the tool can't deal with multiple users, work out a way to script a rename the correct copy for the current user. A clever developer should be able to find an alternative to forcing subversion to keep a versioned directory in conflicting place or retyping a file to recreate it when needed... Of course if it is too much trouble to clean up the files correctly, you can just delete the whole workspace and check out again to go between the branch/trunk versions. Svn can't decide which of your files that it can't recreate for you should disappear. It could ignore files that it is instructed to ignore. That would help. How many people actually know which files subversion is ignoring? Again, a clever developer could probably come up with his own way to delete files matching some patterns if he really wants that to happen. -- Les Mikesell lesmikes...@gmail.com
Re: Switching
On Thu, Aug 22, 2013 at 12:43 PM, John Maher jo...@rotair.com wrote: The clean up script is a good idea but won't work here. We have mostly all class libraries. One executable. This means to test we need to specify an application in the project. Some developers use the exe while some use a tool made just for testing the classes. This information is in the *.sou files which are unversioned for this reason. So we don't want to delete them (as I incorrectly stated somewhere) but ignore them. You are sort-of asking for trouble if you have any dependency 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 that in the future you can use build automation tools like jenkins, relying only on the contents of the repository even when the build happens on a new host. It will simply your life even for manual operations if you can count on that. -- Les Mikesell lesmikes...@gmail.com
RE: Switching
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. -Original Message- From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net] Sent: Thursday, August 22, 2013 1:48 PM To: John 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: Switching The problem isn't something in the way, the problem is something is there when nothing is expected. There is a directory in one 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 complaining that it can not add it because it is there. Okay, this isn't a svn issue. This sounds more like a I did a build against trunk, switched to branch B, and then did a build of B in a dirty workspace. That's just asking for trouble in terms of build accuracy and build repeatability; it's a bad practice in general. The whole trunk, switch to B, switch back to trunk directory conflict may be an annoyance, but a 'make clean' build option or cleanup script run after the switch sounds like something that you need to implement.
Re: Switching
John Maher jo...@rotair.com writes: I use one folder for my source code (all branches) mainly because of vendor requirements the code must be run from the same directory. I have created two branches for two new features. One feature extends an existing library. The other feature adds a new library as well as extending an existing one. When I switch I create a conflict because the directory exists in one branch and not the other: local unversioned, incoming add upon switch This may or may not be what is supposed to happen, that would be the first thing I would like to know. How to fix it would be the second thing that I would like to know. svnadmin create repo svn -mm mkdir file://`pwd`/repo/A svn -mm cp file://`pwd`/repo/A ^/B svn -mm mkdir file://`pwd`/repo/B/X svn co file://`pwd`/repo/B wc touch wc/X/f# an unversioned 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 ? wc/X/f Summary of conflicts: Tree conflicts: 1 The conflict can be resolved by reverting the delete: svn revert -R wc/X svn st wc ? wc/X/f The original unversioned wc/X/f has been preserved across both switches. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
RE: Switching
You are correct that there will be issues with a fresh checkout. But I can live with that. The code will not be affected, just the way the code is tested. Once the developer decides on how they wish to test I do not want to A) lose those changes or B) step on the choices 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 Subject: Re: Switching On Thu, Aug 22, 2013 at 12:43 PM, John Maher jo...@rotair.com wrote: The clean up script is a good idea but won't work here. We have mostly all class libraries. One executable. This means to test we need to specify an application in the project. Some developers use the exe while some use a tool made just for testing the classes. This information is in the *.sou files which are unversioned for this reason. So we don't want to delete them (as I incorrectly stated somewhere) but ignore them. You are sort-of asking for trouble if you have any dependency 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 that in the future you can use build automation tools like jenkins, relying only on the contents of the repository even when the build happens on a new host. It will simply your life even for manual operations if you can count on that. -- Les Mikesell lesmikes...@gmail.com
Re: Switching
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. This can not be changed. So within a single directory we need to version some files and ignore others. Sure I could write a pre-processing program to do a multitude of things. It wouldn't be that hard. But then my plate has plenty of things that are not that hard. What will I gain? Things that don't mysteriously break? Reproducible builds? Are those worth anything? A happy working copy with a single command as long as what I write always works perfectly. Highly unlikely, so then I will make more problems for myself. Plus I assigned myself the task of learning subversion. Covering up a symptom does not treat the disease. If you want to rely on the contents of dirty workspaces, just check out different copies for each branch and let the cruft live there as long as you need it. You can still update/commit independently, etc. But you need to understand that the cruft is yours, not subversion's and whatever you are doing isn't reproducible. -- Les Mikesell lesmikes...@gmail.com
Re: Switching
I agree with Les here on the point about making sure you can automate the process correctly only with versioned resources. In our CI builds we have the versioned resources configured so that all tests are executed every time. Developers execute subsets of tests through their tools and are expected to manage their tools on their own. Sounds like there might be a trade off between copying/reconfiguring if they choose one working copy per branch and reconfiguring if they clean/switch between branches. That might be best left as an individual developer decision. On 8/22/13 10:58 AM, John Maher wrote: You are correct that there will be issues with a fresh checkout. But I can live with that. The code will not be affected, just the way the code is tested. Once the developer decides on how they wish to test I do not want to A) lose those changes or B) step on the choices 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 Subject: Re: Switching On Thu, Aug 22, 2013 at 12:43 PM, John Maher jo...@rotair.com wrote: The clean up script is a good idea but won't work here. We have mostly all class libraries. One executable. This means to test we need to specify an application in the project. Some developers use the exe while some use a tool made just for testing the classes. This information is in the *.sou files which are unversioned for this reason. So we don't want to delete them (as I incorrectly stated somewhere) but ignore them. You are sort-of asking for trouble if you have any dependency 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 that in the future you can use build automation tools like jenkins, relying only on the contents of the repository even when the build happens on a new host. It will simply your life even for manual operations if you can count on that.
Re: Switching
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 everyone doesn't agree with that choice. The code will not be affected, just the way the code is tested. Once the developer decides on how they wish to test I do not want to A) lose those changes or B) step on the choices others have made by versioning it. If this is preliminary testing, maybe that's OK. If it is the whole story, I'd want it to be reproducible. Think config or settings file. Think build automation where you'd want to be able to reproduce these on demand, not just rely on what happens to still live in the current filesystem. It might take a one-time effort to find the files and decide how to handle them (renamed versioned copies, templates, moved local copies, etc.) but then aside from being able to switch among banches, you can reproduce a usable working copy. -- Les Mikesell lesmikes...@gmail.com
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 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 switch like problems on nearly any SCM you use that has the ability to switch a single working copy (or workspace, client, what-have-you) between branches. My knee jerk reaction in situations like this is to fix the build system. Are you sure there is nothing you can do? Perhaps you can suggests a simple fix like moving the versioned class library to a location that is always versioned. For example, instead of referencing a class library that lives in a bin/ directory it is better to keep the class library in a lib/ directory instead. Build output goes in the unversioned bin/ directory and versioned resources go in the lib/ directory. -- Edwin G. Castro
RE: Switching
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, ini file, choose your terminology. If you don'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, 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 everyone doesn't agree with that choice. The code will not be affected, just the way the code is tested. Once the developer decides on how they wish to test I do not want to A) lose those changes or B) step on the choices others have made by versioning it. If this is preliminary testing, maybe that's OK. If it is the whole story, I'd want it to be reproducible. Think config or settings file. Think build automation where you'd want to be able to reproduce these on demand, not just rely on what happens to still live in the current filesystem. It might take a one-time effort to find the files and decide how to handle them (renamed versioned copies, templates, moved local copies, etc.) but then aside from being able to switch among banches, you can reproduce a usable working copy. -- Les Mikesell lesmikes...@gmail.com
Re: Switching
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. Please ask for clarification if you do not understand. You gave a good suggestion with the force option. Then you wandered off to completely irrelevant ramblings. Should quit while you're ahead. It's getting obvious that you're not actually interested in the solutions the list has to give :(
Re: Switching
You said, and I quote, There is a class library in one branch but not in the other mixed with unversioned files that I can do nothing about. I misread that statement to mean you had compiled output committed in one branch. You seem to be trying to point out that the class library is not compiled in the repository. The source code to the class library is. OK, that's fine. The point of fact is that there are unversioned files that I can do nothing about. A few of us are pointing out the potential problems that occur when these unversioned files are important enough that they need to be kept around. You say you can do nothing about the fact that the unversioned files are important. I question whether there is really is nothing you can do. Sometimes tools gently point out that there are deficiencies elsewhere. We should not ignore them. I think the --force option is dangerous. Try it out but, in my opinion, you should not use it. I think Philip Martin's suggestion is a better solution. On 8/22/13 11:39 AM, 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 clarification if you do not understand. You gave a good 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: 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 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 switch like problems on nearly any SCM you use that has the ability to switch a single working copy (or workspace, client, what-have-you) between branches. My knee jerk reaction in situations like this is to fix the build system. Are you sure there is nothing you can do? Perhaps you can suggests a simple fix like moving the versioned class library to a location that is always versioned. For example, instead of referencing a class library that lives in a bin/ directory it is better to keep the class library in a lib/ directory instead. Build output goes in the unversioned bin/ directory and versioned resources go in the lib/ directory. -- Edwin G. Castro
Re: Switching
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 config file, ini file, choose your terminology. If you don't understand please ask for clarification instead of making incorrect assumptions. 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 containing directory that is really the issue, or you have to delete it yourself. Pick one. If it really is always the same, I don't see the problem with committing it. If it isn't, and you need to reproduce it, you need to work out a way to do that, or use the multiple-checkout approach to maintain dirty workspaces, realizing that you can't reproduce them reliably. Personally, I don't like things that rely on any unversioned state getting into production releases. That developer will leave or that machine will crash and all the magic is gone - and if you can't do a matching build on a clean machine from a clean checkout, you won't ever know how much magic was involved. -- Les Mikesell lesmikes...@gmail.com
Re: Switching
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 then delete the containing directory that is really the issue, or you have 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 which contains unversioned files, svn leaves the directory. However, when switching back to the branch with the extra directory it requires that no such directory already exist, even if none of the incoming files have conflicting unversioned twins. 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 nicely compartmentalized units of content which can be handled in a smarter way. -- Les Mikesell lesmikes...@gmail.com -- Travis pgp6IIptVYTgI.pgp Description: PGP signature
Re: Switching
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 then delete the containing directory that is really the issue, or you have to delete it yourself. Pick one. If it really is snip Why must svn delete the directory in order to create it? When it creates it, it will create it as a versioned object with history. What is it supposed to do with that history when it can't create it because there is already an unversioned instance there? Svn doesn't pretend that things that just happen to have the same names are the same object, they actually have to have the same history. Reading this thread it seems to me that the core of the issue is that svn switch is not symmetrical when dealing with directories. I think it would have the same problem with any unversioned object with the same name as the versioned one that it needs to create. 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 nicely compartmentalized units of content which can be handled in a smarter way. No, look at your logs of directory history. They aren't just containers for whatever happens to be there, the history of adds and deletes are there. It might be possible to make things work where it would pretend that it created a directory keeping the history from the repo but ignoring extraneous content, but its not what I'd expect. -- Les Mikesell lesmikes...@gmail.com
Re: Switching
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 nicely compartmentalized units of content which can be handled in a smarter way. No, look at your logs of directory history. They aren't just containers for whatever happens to be there, the history of adds and deletes are there. It might be possible to make things work where it would pretend that it created a directory keeping the history from the repo but ignoring extraneous content, but its not what I'd expect. Directories also have content in the form of properties. The problem is svn doesn't have enough information to make *good* decisions about conflicts between two objects with different histories (regardless of whether the object is a file, directory, or other). Here are some examples: 1.) Two objects added in two different branches have different histories, even if they have the same name and content, causing a tree conflict on merge. 2.) Two objects with the same name where one is versioned (has history) and the other is unversioned (no history) also causes a tree conflict on merge/update/switch/etc. Because a good decision cannot be made, svn punts and requires the user to take action. -- Edwin G. Castro
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 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
requirements the code must be run from the same directory. I have created
two branches for two new features. One feature extends an existing library.
The other feature adds a new library as well as extending an existing one.
When I switch I create a conflict because the directory exists in one branch
and not the other:
That doesn't make sense. If you branched (i.e. created copies of a baseline)
then the dir trees should be identical. Extending/modifying the library
(adding new dirs) shouldn't create a conflict for svn switch, unless you
modified the same directory tree/structure in the workspace's branch and in the
branch you're switching too. This happens if you 'svn add' the same dir in
both branches. Example:
Bad, causes conflict:
svn add ^/branches/foo/new_dir
svn add ^/branches/bar/new_dir
Good:
Svn add ^/branches/foo/new_dir
cd to bar workspace; svn copy ^/branches/foo/new_dir .
It could also happen if you renamed/moved the same dir in both branches.
local unversioned, incoming add upon switch
This sounds like you have a normal, unversioned directory in the workspace. As
part of the switch, svn wants to add a versioned dir of the same name to your
workspace. You should be able to rename the local normal dir to a new name in
order to let the add operation be run unimpeded. I would 'svn revert -R' the
entire workspace[1], rename the normal, local dir, and re-run the switch. And
figure out why you have a normal, unversioned copy of the dir in the first
place.
This may or may not be what is supposed to happen, that would be the first
thing I would like to know. How to fix it would be the second thing that I
would like to know. According to the help of the resolve command says:
So I tried svn resolve -accept working LibraryDirectory but I believe that
was a mistake because then the directory was marked Delete which is not
what I wanted. Does anyone know what is the proper response?
Meh. Resolving tree conflicts is a bit of a manual process. IIRC, to resolve
it, you would need to
1) rename the normal, local dir, and
2) 'svn copy svn://server/.../LibraryDirectory .' Meaning, you need to manually
implement the add. ('svn switch' failed the add so you need to reproduce the
add manually.)
3) 'svn resolve' the dir.
Which is why I recommend just reverting[1] the switch, renaming the dir and
re-running the switch.
The main takeaway is that resolving tree conflicts isn't as easy as resolving
file conflicts. File conflicts let you use the 'mine-full', 'theirs-full',
etc. options, but tree conflicts do not. Fixing tree conflicts requires fixing
up the tree in the workspace yourself and then using 'svn resolve --accept
working' to tell subversion that the tree is now in the state you want. In
other words, you have to manually implement 'theirs-full'.
I did not want to lose the library from the working copy so I switched back
to the other branch and then switch back. Now it says:
local delete, incoming delete upon switch
You (or the failed 'svn switch' command) ran 'svn delete some_dir' in your
workspace. However, the current 'svn switch' also wants to run 'svn delete
some_dir'. So svn switch is complaining that it can't delete the dir because
it's already flagged for deletion. =/
It seems I did something wrong. My next step would be to add the library
back, but that may not be the best response. Any suggestions?
It sounds like you mangled the switch with too many hacks while trying to fix
it, i.e. the workspace is a mess. Just 'svn revert -R'[1], then 'svn status'
to make sure that there are no local/private files that could muck up the
switch.
The thing to remember is that svn is replaying changes on top of your
workspace. It walks the revisions, and for each revision, applies that
revision's changes to the workspace. So if you're applying 10 revisions' worth
of changes and the second revision breaks the switch/merge with a tree
conflict, then you have to manually fix the tree conflict (svn add, svn rm, svn
revert, etc.), resolve it, and then re-run the switch/merge to apply the
renaming 8 revisions.
[1] Before you run 'svn revert -R', run 'svn status' to make sure you don't
have any modified, uncommitted files that you really care about. Revert will
delete those changes.
RE: Switching
Thanks for your reply. I agree it does not make sense. But it is reproducible. The dir trees are NOT identical because one branch has a library that the other does not. In normal use I would expect the branches to differ. And I assure you one of the branches does not have the directory causing the trouble, I checked on the server. So the branches are different and it appears impossible to switch between them without conflicts. For example, when I switch to branch P it switches OK. An svn status on the problem directory shows it with a '?'. Then I switch to branch E and get a conflict. It says local unversioned, incoming add upon switch. The local should be unversioned, it is not part of branch P. I do not know why the directory did not get deleted during the switch. An svn status shows the directory marked for deletion. So in one instance of time I get a message of a directory that is unversioned, incoming add, marked for deletion. Svn revert does not do anything useful. So I then issue svn resolve --accept working UI_Email where UI_Email is the directory causing the problems. This clears the conflict. Then I switch to branch P. Then is says local delete, incoming delete. Why it has a local delete is beyond me. That folder is part of the branch, I want it there and never issued a delete. But subversion did. So I resolve this conflict the same as the last one and switch back to branch E. You guessed it, conflict again. So I resolve the conflict then commit and decide to let subversion delete the directory (I have a backup because I've lost code to subversion before). So now my code is gone. I delete the directory with supporting files. Then I switch to branch P. Success for now (I know failure is just a matter of time). Then I switch to branch E. No conflict. 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 switch to branch P. This is where the problem arises. Subversion deletes the files but not the directory because it contains files that do not belong in subversion. I have no control over this as the compiler puts them there. They are on the global ignore list. Now when I switch the conflict returns. Nothing in the book explains how to handle this. Searching comes up with all kinds of irrelevant stuff and unanswered questions. My question is how to properly handle this? Or is branching unusable in this situation with out the extra hassle? Thanks JM -Original 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 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 to make sure I am not making any mistakes. I use one folder for my source code (all branches) mainly because of vendor requirements the code must be run from the same directory. I have created two branches for two new features. One feature extends an existing library. The other feature adds a new library as well as extending an existing one. When I switch I create a conflict because the directory exists in one branch and not the other: That doesn't make sense. If you branched (i.e. created copies of a baseline) then the dir trees should be identical. Extending/modifying the library (adding new dirs) shouldn't create a conflict for svn switch, unless you modified the same directory tree/structure in the workspace's branch and in the branch you're switching too. This happens if you 'svn add' the same dir in both branches. Example: Bad, causes conflict: svn add ^/branches/foo/new_dir svn add ^/branches/bar/new_dir Good: Svn add ^/branches/foo/new_dir cd to bar workspace; svn copy ^/branches/foo/new_dir . It could also happen if you renamed/moved the same dir in both branches. local unversioned, incoming add upon switch This sounds like you have a normal, unversioned directory in the workspace. As part of the switch, svn wants to add a versioned dir of the same name to your workspace. You should be able to rename the local normal dir to a new name in order to let the add operation be run unimpeded. I would 'svn revert -R' the entire workspace[1], rename the normal, local dir, and re-run the switch. And figure out why you have a normal, unversioned copy of the dir in the first place. This may or may not be what is supposed to happen, that would be the first thing I would like to know. How to fix it would be the second thing that I would like to know. According to the help
RE: Switching
-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 because one branch has a library that the other does not. In normal use I would expect the branches to differ. And I assure you one of the branches does not have the directory causing the trouble, I checked on the server. So the branches are different and it appears impossible to switch between them without conflicts. For example, when I switch to branch P it switches OK. An svn status on the problem directory shows it with a '?'. Then I switch to branch E and get a conflict. It says local unversioned, incoming add upon switch. The local should be unversioned, it is not part of branch P. I do not know why the directory did not get deleted during the switch. An svn status shows the directory marked for deletion. So in one instance of time I get a message of a directory that is unversioned, incoming add, marked for deletion. When removing dirs, switch will not delete local/private/unversioned files. If there is a local file in a dir tree, then all the versioned files will be removed from your workspace, but a local tree will remain with the local files still in it. That's mostly likely why you see a '?' after the switch. Ex: 1. 'this_dir' exists in current workspace as a versioned dir tree. 2. 'this_dir' does NOT exist in branch P. 3. touch this_dir/hello_world.txt 3. svn switch ^/branches/P 4. svn status: ? this_dir The only file under this_dir will be hello_world.txt. All other versioned files/dirs will have been removed. Svn revert does not do anything useful. So I then issue svn resolve -- accept working UI_Email where UI_Email is the directory causing the problems. This clears the conflict. Then I switch to branch P. Then is says local delete, incoming delete. Why it has a local delete is beyond me. That folder is part of the branch, I want it there and never issued a delete. But subversion did. So I resolve this conflict the same as the last one and switch back to branch E. You guessed it, conflict again. You shot yourself in the foot. =) The local copy of the dir prevented switch from running the add. (Switch wasn't able to pull in the versioned copy of the dir.) Then you didn't fix the dir conflict by manually running 'svn copy' yourself to pull in the dir from branch P. When you did the resolve, you told svn that the current state of the dir is correct, and since the current state of the dir was effectively deleted, you wound up telling svn to delete the file from branch P. Again, when resolving tree conflicts, you need to manually copy/add/delete/mv manipulate the tree into the correct state before resolving the tree conflict. So I resolve the conflict then commit and decide to let subversion delete the directory (I have a backup because I've lost code to subversion before). So now my code is gone. I delete the directory with supporting files. Then I switch to branch P. Success for now (I know failure is just a matter of time). You can recover the deleted versioned dirs and files via peg revisions. http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.resurrect Then I switch to branch E. No conflict. 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. Right. You deleted the dir from branch P. And you deleted the local/private files/tree as well. Thus no conflict with branch E. However, if you want to get the dir into branch E, then you should have merged from branch P to branch E (or used 'svn copy ^/branches/P/some_dir ^/branches/E/some_dir.) (But you'll need to restore the dir in branch P first via 'svn copy' and a peg revision.) So I copy over the directory and do a svn add then commit. Then I can switch to branch P. Argh. No, no, no. That creates evil twins. What you should have done was 'svn copy svn:///some_dir@1234 some_dir to add the dir back in. When you run 'svn add' you create brand new objects with no history. Evil twins break merging. This is where the problem arises. Subversion deletes the files but not the directory because it contains files that do not belong in subversion. I have no control over this as the compiler puts them there. They are on the global ignore list. Svn switch won't delete your local/private files because that would be rude, where rude equals destroying the user's files. So if you're switching, you need to manage private/local files. Maybe run 'make clean' (assuming you have a clean option) before switching? Or tweak your build script to put all build output in its own dir, instead
Re: Switching
Guten Tag John Maher, am Dienstag, 20. August 2013 um 19:33 schrieben Sie: For example, when I switch to branch P it switches OK. Where did you switch from? Does this branch contain the directory which is responsible for the later mentioned error message? It has been created by someone of course, either by svn because it's part of branch or by something other like a build tool. An svn status on the problem directory shows it with a '?'. Then I switch to branch E and get a conflict. It says local unversioned, incoming add upon switch. Which is correct behavior as the director is present, but not versioned. The local should be unversioned, it is not part of branch P. I do not know why the directory did not get deleted during the switch. Surely because it contained unversioned data itself and therefor couldn't be deleted by svn as it tries to never delete unversioned data. Svn revert does not do anything useful. So I then issue svn resolve --accept working UI_Email where UI_Email is the directory causing the problems. This clears the conflict. Of course, that's what resolve is meant for ;-), but the interesting thing is the data in the directory. It may not contain all the files and dirs need from your branch E where the directory is versioned in. Then I switch to branch P. Then is says local delete, incoming delete. Why it has a local delete is beyond me. This could be because your conflict resolution which may be missing data which should be present in the director yin branch E, an is not in your local working copy. This means something has changed but didn't get committed because you switched instead of first committing the changes from your conflict resolution. So I resolve the conflict then commit and decide to let subversion delete the directory (I have a backup because I've lost code to subversion before). You never lose code unless you lose your repo, the only thing may be that you don't know how to revert to older revisions. ;-) And yes, I often have the same problem using the console applications and prefer using Tortoise instead in those cases. Then I switch to branch E. No conflict. Of course, because the directory is missing, which is different to what you have described in the 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 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 switch to branch P. This is where the problem arises. Subversion deletes the files but not the directory because it contains files that do not belong in subversion. That's the info which should have been in the first mail and the start of this one. :-) I have no control over this as the compiler puts them there. They are on the global ignore list. And subversion can't know how important those files are for you and therefor can't just delete them. This problem is up to you, you need to delete them on your own after switching to branch P if you don't need the directory in your working copy. My question is how to properly handle this? Or is branching unusable in this situation with out the extra hassle? As subversion can't know what to do with unversioned files, it leaves them as they are where they are. It is up to you to clean up your working copy in such a way that it doesn't contain any mess which prevents you from switching between different branches. 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
