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: using svn merge, svn diff, and svn patch
So other then tar-ing up the WC, there is no way to reproduce local changes like this on another system? I know the example given is fairly simple, but it could be very useful. -Jim On Tue, Aug 20, 2013 at 3:28 PM, Stefan Sperling s...@elego.de wrote: On Tue, Aug 20, 2013 at 01:16:40PM -0400, James Hanley wrote: Not sure if this is a valid operation, but should I be able to use svn merge, then svn diff to create a patch, then svn patch on another branch (or pristine checkout of the originating branch where the diff was created) to create a replica of the merge operation? No. 'svn patch' is not intended to be a drop-in replacement for 'svn merge'. The reason I ask is that it appears not to do that.. I get an Skipped missing target error on one file that was added with history with the merge, I guess what happened is that you didn't use the --show-copies-as-adds option for 'svn diff' when you created the diff. svn patch cannot handle copies, only additions, due to restrictions of the unidiff format. another in the same path that doesn't error or add, and apparently no mergeinfo included at all. svn patch doesn't support mergeinfo either. See http://subversion.tigris.org/issues/show_bug.cgi?id=3747
Feature Req: ability to specify a changelist for svn merge
ie: svn merge -cl merge_from_trunk https://svn.somerepo.com/project/trunk #Any items merged in are added to change list merge_from_trunk to # easily differentiate from local changes that the user does not want to check in svn status M local_file_changes.txt --- Changelist 'merge_from_trunk': M . M pathhere/foo.c M pathhere/bar.c A +paththere/mon.h M paththere/mon.cpp M pathoverthere/foo This would then allow just the easy checkin of the merge with svn ci -cl merge_from_trunk alternatively (if easier to implement) the ability to specify to svn ci the set of files not specified as a member to a changelist. -Jim
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: How Big A Dump File Can Be Handled? (svn 1.8 upgrade)
On 8/21/2013 7:13 PM, Geoff Field wrote: I'm keeping the original BDB
repositories, with read-only permissions.
If I really have the need, I can restart Apache 2 with SVN 1.2.3 and
go back to the original repositories. Otherwise, I also have the
option of re-running my batch file (modifying it if absolutely
required). On top of that, there are bunches of files on another
server that give us at least the latest state of the projects. The
dump files in this case are not really as useful as the data itself.
Regards, Geoff
When we did our 1.6 to 1.8 upgrade a few weeks ago, I used the following
steps (ours was an in-place upgrade, so a bit of extra checking was added):
0. Back everything up, twice.
1. Check the version of the repository to see whether it is already 1.8
BASE='/var/svn/'
TARGET='/backup/svndump/'
DIR='somereponame'
SVNADMIN=/path/to/svnadmin
REPOFMT=`grep '^[123456]$' ${BASE}${DIR}/db/format`
echo FSVS database format is $REPOFMT
if [ $REPOFMT -ge 6 ]; then
echo Format = 6, not upgrading.
continue
fi
Note: That was a quick-n-dirty check that was valid for our
configuration. To be truly correct, you need to verify:
reponame/format
reponame/db/fs-type
reponame/db/format
2. Strip permissions on the original repo down to read-only.
3. Ran svnadmin verify on the original repository.
echo Run svnadmin verify...
$SVNADMIN verify --quiet ${BASE}${DIR}
status=$?
if [ $status -ne 0 ]; then
echo svnadmin verify failed with status: $status
continue
else
echo svnadmin verify succeeded
fi
4. Do the svnadmin dump, piping the output into gzip -5 (moderate
compression).
echo svnadmin dump...
$SVNADMIN dump --quiet ${BASE}${DIR} | gzip -5 --rsyncable
${TARGET}${DIR}.dump.gz
status=$?
if [ $status -ne 0 ]; then
echo svnadmin dump failed with status: $status
continue
fi
5. Remove the old repository directory.
echo Remove old repository (dangerous)
rm -rf ${BASE}${DIR}
status=$?
if [ $status -ne 0 ]; then
echo remove failed with status: $status
continue
fi
6. Create the repository in svn 1.8.
echo Recreate repository with svnadmin
$SVNADMIN create ${BASE}${DIR}
status=$?
if [ $status -ne 0 ]; then
echo svnadmin create failed with status: $status
continue
fi
7. Strip permissions on the repository back down to 700, owned by
root:root while we reload the data.
8. Fix the db/fsfs.conf file to take advantage of new features.
Note: Make sure you understand what enable-dir-deltification,
enable-props-deltification and enable-rep-sharing do. Some of these are
not turned on in SVN 1.8 by default.
echo Fix db/fsfs.conf file
sed 's/^[#[:space:]]*enable-rep-sharing =
false[#[:space:]]*$/enable-rep-sharing =
true/g;s/^[#[:space:]]*enable-dir-deltificati
on = false[#[:space:]]*$/enable-dir-deltification =
true/g;s/^[#[:space:]]*enable-props-deltification =
false[#[:space:]]*$/enable-p
rops-deltification = true/g' --in-place=.bkp ${BASE}${DIR}/db/fsfs.conf
status=$?
if [ $status -ne 0 ]; then
echo sed adjustment of db/fsfs.conf failed with status: $status
continue
fi
9. Load the repository back from the dump file.
echo svnadmin load...
gzip -c -d ${TARGET}${DIR}.dump.gz | $SVNADMIN load --quiet ${BASE}${DIR}
status=$?
if [ $status -ne 0 ]; then
echo svnadmin load failed with status: $status
continue
fi
10. Run svnadmin pack to pack revs/revprops files (saves on inodes).
echo svnadmin pack...
$SVNADMIN pack --quiet ${BASE}${DIR}
status=$?
if [ $status -ne 0 ]; then
echo svnadmin pack failed with status: $status
continue
fi
11. Run svnadmin verify.
echo Run svnadmin verify...
$SVNADMIN verify --quiet ${BASE}${DIR}
status=$?
if [ $status -ne 0 ]; then
echo svnadmin verify failed with status: $status
continue
else
echo svnadmin verify succeeded
fi
12. Restore original permissions.
Note: I have a custom script that I can run to set permissions correctly
on our repository directories. I never set file system permissions by
hand on the repositories, I always update the script and then use that.
(With a few hundred repositories, I have to be organized and rely on
scripts.)
13. Back everything up again, twice.
All-in-all, it took us a few days to convert 110GB of repositories
(mostly in 1.6 format), but the resulting size was only 95GB and far
fewer files (due to revprops packing in 1.8). Our nightly backup window
went from about 3 hours, down to 30 minutes from using svnadmin hotcopy
--incremental. When then use rdiff-backup to push the hotcopy
directory to a backup server.
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: Feature Req: ability to specify a changelist for svn merge
On 22.08.2013 15:55, James Hanley wrote: ie: svn merge -cl merge_from_trunk https://svn.somerepo.com/project/trunk #Any items merged in are added to change list merge_from_trunk to # easily differentiate from local changes that the user does not want to check in svn status M local_file_changes.txt --- Changelist 'merge_from_trunk': M . M pathhere/foo.c M pathhere/bar.c A +paththere/mon.h M paththere/mon.cpp M pathoverthere/foo This would then allow just the easy checkin of the merge with svn ci -cl merge_from_trunk The idea sort of goes aginst the grain of what changelists actually are. With a changelist, you essentially label a number of files in the working copy, but in the merge scenario you're trying to use them to limit the set of merge sources, i.e., a set of objects in the repository (which may or may not have the same names in the working copy). alternatively (if easier to implement) the ability to specify to svn ci the set of files not specified as a member to a changelist. ISTR this has already been discussed somewhere ... yup, here it is: http://subversion.tigris.org/issues/show_bug.cgi?id=3348 http://mail-archives.apache.org/mod_mbox/subversion-dev/201301.mbox/%3c50e71e20.6070...@collab.net%3E -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Feature Req: ability to specify a changelist for svn merge
On 8/22/13 6:55 AM, James Hanley wrote: ie: svn merge -cl merge_from_trunk https://svn.somerepo.com/project/trunk #Any items merged in are added to change list merge_from_trunk to # easily differentiate from local changes that the user does not want to check in svn status M local_file_changes.txt --- Changelist 'merge_from_trunk': M . M pathhere/foo.c M pathhere/bar.c A +paththere/mon.h M paththere/mon.cpp M pathoverthere/foo This would then allow just the easy checkin of the merge with svn ci -cl merge_from_trunk alternatively (if easier to implement) the ability to specify to svn ci the set of files not specified as a member to a changelist. -Jim Out of curiosity, what do you propose should happen if the merge needs to make changes to local_file_changes.txt? -- 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
Feature Req: sorthand urls for branches/tags in CLI
Dear subversion users, developers, I'm working on a project where we are actively working on many branches. It works great. Despite all the IDE support I have, as a build and release engineer, I need to work a lot from command line. Addressing branches/tags could be a pain from command line especially when you would like to compare or see log for a file deep in hierarchy. I'd propose a -b [--branch] option or extend the meaning of ^ sign for those commands which can work with URL-s. Extending ˇ would mean that when used as ^/ it means repository root and using it as ^[branch] then it would refer to a branch. How would it work: Let's imagine the following repository layout: /project1/trunk /project1/trunk/dir1/dir2/dir3/fileA /project1/branches/branchA /project1/branches/branchA/dir1/dir2/dir3/fileA /project1/branches/branchB /project1/branches/branchB/dir1/dir2/dir3/fileA /project1/tags/tag1 /project1/tags/tag2 Use Case 1: We are in the WC root of checked out trunk and would like merge branchA back. svn merge -b branchA svn merge ^branchA Use Case 2: We are in dir1/dir2/dir3 in WC of checked out branchB and would would like to see what has happened on trunk in this folder: svn log -l 3 -b trunk svn log -l 3 ^trunk Use Case 3: We are in dir1/dir2/dir3 in WC of checked out branchB and would would like to see what is the difference in fileA between our working copy and branchA: svn diff -b branchA fileA svn diff ^branchA fileA Implementation ideas: We put a specific property on project1 folder let's call it svn:branches for now. Here we could describe the layout of branches and tags for that part of repository. E.g.: a) Using prefixes: / /branches/ /tags/ b) Using some custom mapping/lists: trunk branches/* tags/* c) Using regexp captures: (trunk) branches/(\w+) tags/(\w+) Having this info, the path where this property is set, the name of the branch and the current path relative to wc root it is possible to construct a repository URL to be used. As far as I currently see there would be no change required on server side.
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: How Big A Dump File Can Be Handled? (svn 1.8 upgrade)
Hi Thomas, From: Thomas Harold Sent: Friday, 23 August 2013 1:25 AM On 8/21/2013 7:13 PM, Geoff Field wrote: I'm keeping the original BDB repositories, with read-only permissions. If I really have the need, I can restart Apache 2 with SVN 1.2.3 and go back to the original repositories When we did our 1.6 to 1.8 upgrade a few weeks ago, I used the following steps (ours was an in-place upgrade, so a bit of extra checking was added): 0. Back everything up, twice. Our servers have nightly backups that I know to work (from experience). I also didn't get rid of the originals (as stated). 1. Check the version of the repository to see whether it is already 1.8 I *knew* that all of our repositories were in the 1.2 format. That's the only version we had for years on end. ... 2. Strip permissions on the original repo down to read-only. I didn't bother with that, since I didn't do any write operations on the repos (other than changing the names. However, I *did* change the repo access permissions in the authz file. 3. Ran svnadmin verify on the original repository. Probably something I should have done, but luckily I ended up with no obvious failures in the dumps. 4. Do the svnadmin dump, piping the output into gzip -5 (moderate compression). If you're removing the old repo, I suppose it makes sense to keep the dump file. Compression would make it less onerous in storage terms. 5. Remove the old repository directory. I agree with what the script echoes - dangerous 6. Create the repository in svn 1.8. I'm sure there's an upgrade command that would do it all in-place. 7. Strip permissions on the repository back down to 700, owned by root:root while we reload the data. While, or before? 8. Fix the db/fsfs.conf file to take advantage of new features. Note: Make sure you understand what enable-dir-deltification, enable-props-deltification and enable-rep-sharing do. Some of these are not turned on in SVN 1.8 by default. There are features we're very unlikely to need at this stage in our company existence. 9. Load the repository back from the dump file. At last! 10. Run svnadmin pack to pack revs/revprops files (saves on inodes). Makes sense 11. Run svnadmin verify. Always a good thing to do. 12. Restore original permissions. Fair enough. Note: I have a custom script that I can run to set permissions correctly on our repository directories. I never set file system permissions by hand on the repositories, I always update the script and then use that. (With a few hundred repositories, I have to be organized and rely on scripts.) On your OS, is there a way to read the permissions first? 13. Back everything up again, twice. You're not paranoid if they really *are* out to get you... ;-) All-in-all, it took us a few days to convert 110GB of repositories (mostly in 1.6 format), but the resulting size was only 95GB and far fewer files (due to revprops packing in 1.8). Our nightly backup window went from about 3 hours, down to 30 minutes from using svnadmin hotcopy --incremental. When then use rdiff-backup to push the hotcopy directory to a backup server. I've just surprised myself by checking the file system properties. After the BDB-FSFS conversion, we now have 164 repositories, totallying 312GB on the disk. That's a LOT of backup space requirement. Luckily for me, that's all handled by our IT department and is done on their SAN via an automatic utility. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
Re: Feature Req: sorthand urls for branches/tags in CLI
Laszlo Kishalmi wrote on Thu, Aug 22, 2013 at 23:15:04 +0200: Implementation ideas: We put a specific property on project1 folder let's call it svn:branches for now. Here we could describe the layout of branches and tags for that part of repository. E.g.: a) Using prefixes: / /branches/ /tags/ b) Using some custom mapping/lists: trunk branches/* tags/* c) Using regexp captures: (trunk) branches/(\w+) tags/(\w+) Having this info, the path where this property is set, the name of the branch and the current path relative to wc root it is possible to construct a repository URL to be used. How do you handle collisions --- e.g., branches/foo and tags/foo ? As far as I currently see there would be no change required on server side. Yes. There's the svn:externals parser to consider but it's client-side too.
Re: svn 1.8 causing locks to be broken on update
Johan Corveleyn jcor...@gmail.com writes: Now, playing user's advocate: is there still something useful to do here? I.e. apparently ra_neon worked fine with the broken servers. Should ra_serf also be able to handle this, so 1.8 clients can still work fine with servers 1.6.17? It appears to be related to a path handling bug in code that is supposed to handle old servers, the obvious fix makes the problem worse. I've raised http://subversion.tigris.org/issues/show_bug.cgi?id=4412 -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data* Hi Philip How is this bug fix progressing? Cheers, Felipe
Re: How Big A Dump File Can Be Handled? (svn 1.8 upgrade)
On 8/22/2013 7:11 PM, Geoff Field wrote: 6. Create the repository in svn 1.8. I'm sure there's an upgrade command that would do it all in-place. 7. Strip permissions on the repository back down to 700, owned by root:root while we reload the data. While, or before? Step 6 created the repos in our system with writable permissions, so we had to make sure nobody could commit to the repo while we loaded back i the dump file in step 9. Most restores for us took about 5-10 minutes, a few of our larger repos took a few hours. On your OS, is there a way to read the permissions first? Mmm, we could have used stat -c 0%a /path/to/file, but with the script to set our permissions, and because we structure our repos as category-reponame, we can set permissions across entire categories easily with the script. Since we use svn+ssh, repository permissions matter a bit more for us.
RE: How Big A Dump File Can Be Handled? (svn 1.8 upgrade)
From: Thomas Harold Sent: Friday, 23 August 2013 11:53 AM On 8/22/2013 7:11 PM, Geoff Field wrote: Most restores for us took about 5-10 minutes, a few of our larger repos took a few hours. I was doing this all in the background via remote login to our SVN server, so I didn't monitor times. Some of our repos only took seconds because there wasn't much to load. The ones that involved more people and more changes took up to somewhere on the order of an hour or so. Usually, I'd just set it going and do other work while occasionally glancing at the remote desktop session to see if it had finished the current step. Since we use svn+ssh, repository permissions matter a bit more for us. We only allow https access and we only have a few users now, so monitoring and controlling access during the changeover was easy. Besides, nobody was ABLE to access the BDB repositories because the more recent server builds that you can download don't include the BDB module. Simply stopping the old server software was enough to kill all access to the BDB repositories in our case. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
Seg fault when committing 'forks' with svn 1.8.1 client
I have a project that I need to fork (in the same repo): $ svn cp foo bar $ svn rm bar/trunk/some_dir $ svn rm bar/trunk/some_file $ emacs bart/trunk/other_files $ svn ci Segmentation fault: 11 I use the 1.8.1 client from macports: $ svn --version svn, version 1.8.1 (r1503906) compiled Aug 13 2013, 12:59:06 on x86_64-apple-darwin12.3.0 Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme This is the backtrace according to gdb: $ gdb svn GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (Wed Feb 6 22:51:23 UTC 2013) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-apple-darwin...Reading symbols for shared libraries ... done (gdb) r -F svn-commit.tmp ci lpupdates Starting program: /opt/local/bin/svn -F svn-commit.tmp ci lpupdates Reading symbols for shared libraries ++ done Adding bar Sendingbar/trunk/jenkins_build Sendingbar/trunk/shn_bin/common.py Sendingbar/trunk/shn_bin/configure.py Deleting bar/trunk/shn_bin/dependencies Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x 0x7fff90f816b0 in strlen () (gdb) bt #0 0x7fff90f816b0 in strlen () #1 0x0001003efcf2 in svn_path_join_internal () #2 0x00010037ab0e in checkout_dir () #3 0x00010037862c in delete_entry () #4 0x000100056f69 in do_item_commit () #5 0x0001003c4415 in svn_delta_path_driver2 () #6 0x000100056b00 in svn_client__do_commit () #7 0x000100055a7d in svn_client_commit6 () #8 0x0001ae71 in svn_cl__commit () #9 0x00010001b8b2 in sub_main () #10 0x000100019ee2 in main () If I commit with a svn 1.7 client to the same server it works (but it is a pain to do since the 1.8 working format is not compatible with 1.7). The server is still running svn 1.6.x. I've reproduced this behavior over forking 3 small projects so far.
Re: server config
Hi all, I appreciate all the tips and info I've received from my server config questions. It looks like I need to do much more to secure my server before tackling he SVN portion. I'm going to take a step back and do that first. If necessary I'll (re)post once that's complete. Thanks! Scott On Aug 19, 2013, at 12:13 PM, Scott Frankel wrote: Hi all, Thanks for the replies! Please see below for additional comments. On Aug 19, 2013, at 9:42 AM, David Chapman wrote: On 8/19/2013 9:07 AM, Scott Frankel wrote: Hi all, I'm new to SVN server configuration and find myself setting up a CentOS 6.4 server with svn version 1.6.1, following the red-bean book. I'm having difficulty with authorization /or authentication: my repo appears to be accessible by anyone in spite of requiring valid-user and specifying digest authentication. I believe this because 1) I can download a full working copy of the repo to a 3rd-party logged into a foreign computer, and 2) I have dozens of entries in apache's logfiles, like these from this morning, *prior* to any known/legitimate access to my repos today: Step 1: Take the real repo offline until you get the security problems resolved. Every IP address on the Internet is scanned every single day, and your repo is vulnerable right now. Step 2: Run experiments with a dummy repo to resolve the security problems. Don't ever run security experiments with production data. Put production data online only after you know that all security problems have been resolved. Good points! My repo currently being downloaded by whomever is a testProj with absolutely nothing of value in it. svn_logfile: [19/Aug/2013:00:46:32 +] - checkout-or-export / r1 depth=infinity This does not look good at all. It's quite possible that someone else has downloaded your repository. The access_log file may tell you the IP address from which the request was made; with luck it's the one you were experimenting with and the time stamp matches your access. access_log 93.174.93.213 - - [19/Aug/2013:07:23:50 +] GET /w00tw00t.at.blackhats.romanian.anti-sec:) HTTP/1.1 404 319 - ZmEu If you watch access_log over time, as I do, you will see these sorts of probes constantly. Too many to list, they are meant to check for known vulnerabilities in older versions of Apache or tools installed (SQL administration, PHP administration, etc.). These will never go away. Get used to them. They should all fail; if not then you have other security problems to fix. OK. Getting used to common log entries is important. error_log [Mon Aug 19 07:23:51 2013] [error] [client 93.174.93.213] File does not exist: /var/www/html/MyAdmin This doesn't look good at all. My Location directive follows below. The /etc/svn-auth.htdigest exists and appears to be valid. My goal is to setup the repo, serve it via Apache, provide access to only a small number of people that I approve, use cmd-line svn and do so securely. These are standard goals. Good. I mention them in hopes it whittles-down in advance any suggestions you might have. eg: the red-bean book has quite a lot to say about tunneling svnserve, which is not germane to my setup. This is my first brush with Apache, OpenSSL, and general server config. Thanks in advance for your suggestions! BTW, I'm not subscribed and would appreciate being cc'd on any replies. Scott Location /svn DAV svn SVNParentPath /var/svn # Authentication: Digest AuthName Subversion repository AuthType Digest AuthUserFile /etc/svn-auth.htdigest # Authorization: Authenticated users only Require valid-user /Location How many repositories do you have? You shouldn't use SVNParentPath if you have only one repository; use SVNPath. I don't know if that is the direct cause of your problem, but you should fix it. I chose to use SVNParentPath on purpose. As soon as I have a secure, working server config, I'll be hosting multiple repos. Daniel and Thomas, thanks for your suggestions. You can also try working with AuthType Basic, creating passwords with /usr/sbin/htpasswd, until you figure things out. I have more experience with that than AuthType Digest, so I can't help you there. I'll try that to see what I discover; but ultimately my research so far points to Digest mode being more secure. Thanks for the suggestions! Scott -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: server config
Hi all, I appreciate all the tips and info I've received from my server config questions. It looks like I need to do much more to secure my server before tackling he SVN portion. I'm going to take a step back and do that first. If necessary I'll (re)post once that's complete. Thanks! Scott On Aug 19, 2013, at 12:13 PM, Scott Frankel wrote: Hi all, Thanks for the replies! Please see below for additional comments. On Aug 19, 2013, at 9:42 AM, David Chapman wrote: On 8/19/2013 9:07 AM, Scott Frankel wrote: Hi all, I'm new to SVN server configuration and find myself setting up a CentOS 6.4 server with svn version 1.6.1, following the red-bean book. I'm having difficulty with authorization /or authentication: my repo appears to be accessible by anyone in spite of requiring valid-user and specifying digest authentication. I believe this because 1) I can download a full working copy of the repo to a 3rd-party logged into a foreign computer, and 2) I have dozens of entries in apache's logfiles, like these from this morning, *prior* to any known/legitimate access to my repos today: Step 1: Take the real repo offline until you get the security problems resolved. Every IP address on the Internet is scanned every single day, and your repo is vulnerable right now. Step 2: Run experiments with a dummy repo to resolve the security problems. Don't ever run security experiments with production data. Put production data online only after you know that all security problems have been resolved. Good points! My repo currently being downloaded by whomever is a testProj with absolutely nothing of value in it. svn_logfile: [19/Aug/2013:00:46:32 +] - checkout-or-export / r1 depth=infinity This does not look good at all. It's quite possible that someone else has downloaded your repository. The access_log file may tell you the IP address from which the request was made; with luck it's the one you were experimenting with and the time stamp matches your access. access_log 93.174.93.213 - - [19/Aug/2013:07:23:50 +] GET /w00tw00t.at.blackhats.romanian.anti-sec:) HTTP/1.1 404 319 - ZmEu If you watch access_log over time, as I do, you will see these sorts of probes constantly. Too many to list, they are meant to check for known vulnerabilities in older versions of Apache or tools installed (SQL administration, PHP administration, etc.). These will never go away. Get used to them. They should all fail; if not then you have other security problems to fix. OK. Getting used to common log entries is important. error_log [Mon Aug 19 07:23:51 2013] [error] [client 93.174.93.213] File does not exist: /var/www/html/MyAdmin This doesn't look good at all. My Location directive follows below. The /etc/svn-auth.htdigest exists and appears to be valid. My goal is to setup the repo, serve it via Apache, provide access to only a small number of people that I approve, use cmd-line svn and do so securely. These are standard goals. Good. I mention them in hopes it whittles-down in advance any suggestions you might have. eg: the red-bean book has quite a lot to say about tunneling svnserve, which is not germane to my setup. This is my first brush with Apache, OpenSSL, and general server config. Thanks in advance for your suggestions! BTW, I'm not subscribed and would appreciate being cc'd on any replies. Scott Location /svn DAV svn SVNParentPath /var/svn # Authentication: Digest AuthName Subversion repository AuthType Digest AuthUserFile /etc/svn-auth.htdigest # Authorization: Authenticated users only Require valid-user /Location How many repositories do you have? You shouldn't use SVNParentPath if you have only one repository; use SVNPath. I don't know if that is the direct cause of your problem, but you should fix it. I chose to use SVNParentPath on purpose. As soon as I have a secure, working server config, I'll be hosting multiple repos. Daniel and Thomas, thanks for your suggestions. You can also try working with AuthType Basic, creating passwords with /usr/sbin/htpasswd, until you figure things out. I have more experience with that than AuthType Digest, so I can't help you there. I'll try that to see what I discover; but ultimately my research so far points to Digest mode being more secure. Thanks for the suggestions! Scott -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: Feature Req: sorthand urls for branches/tags in CLI
On 8/22/13 2:15 PM, Laszlo Kishalmi wrote: I'd propose a -b [--branch] option or extend the meaning of ^ sign for those commands which can work with URL-s. Extending ˇ would mean that when used as ^/ it means repository root and using it as ^[branch] then it would refer to a branch. How would it work: Let's imagine the following repository layout: /project1/trunk /project1/trunk/dir1/dir2/dir3/fileA /project1/branches/branchA /project1/branches/branchA/dir1/dir2/dir3/fileA /project1/branches/branchB /project1/branches/branchB/dir1/dir2/dir3/fileA /project1/tags/tag1 /project1/tags/tag2 Use Case 1: We are in the WC root of checked out trunk and would like merge branchA back. svn merge -b branchA svn merge ^branchA I'm not sure how I see that this is so much better than just doing: svn merge ^/project1/branches/branchA I type these sort of things routinely with our own Subversion repo as: ^/subversion/trunk and ^/subversion/branches/1.8.x on a regular basis. If you want to make quickly aliases why not just use the variable support of your shell? E.G. with bash: branchA=^/project1/branches/branchA svn merge $branchA Or heck you can make it even shorter to type: bA=^/project1/branches/branchA svn merge $bA I used to do shell variables a lot before ^/ was added. That's back when we were hosted on subversion.tigris.org and we didn't have other projects in our repo and our trunk was a child of the root. With ^/ even with the subversion parent above our repo I just don't find myself using the variables. I'm sure you can probably even get your shell to be fancy and figure out what project you're working in and apply the proper root (you have access to this with svn info). Additionally I'm concerned that this just confuses the meaning for users of how ^/ works. I can already see the user complaints that Subversion merged the wrong thing for them because they forget -b. Let's just say that at this point I'm skeptical of the need for this.
