Re: Strange behavior after replacing directory
On Mon, Sep 30, 2013 at 10:58:35AM +0300, Florin Avram wrote: Hi, I've found a strange behavior in the situation described below and wanted to let you know - I think there could be an issue or a need of improvement (don't know what exactly). Subversion: 1.8.x, 1.7.x. The situation is as follows (the minimum necessary to reproduce the issue): - have a working copy with a folder and a file inside the folder; - replace the folder and commit: svn delete folder/file svn delete --keep-local folder svn add folder (consider it as a new folder) svn commit folder (both folder and file) make new file inside folder svn add folder/file svn commit folder/file - now, in another working copy: svn status -u- reports folder as replaced and file as deleted svn update folder/file - svn indicates that file was updated fine svn statsus -u - again, both folder and file are reported as previously (replaced and deleted) Repeating the file update and svn status goes on and on as file updated correctly and file reported as deleted again. Only after updating the folder everything works fine. My question(s): - is this OK to happen like this? Yes, absolutely. The 'svn update folder/file' step creates a mixed-revision working copy (child is newer than its parent) and you then query the parent with 'status -u' so you get results for the parent, not the child. See http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.basic.in-action.mixedrevs
Re: Strange behavior after replacing directory
Hi, Thank you for the quick reply. Strange thing. I was expecting that the repository will notify me only about the items/revisions/changes I am missing. If the update of the file was successful, then when svn status -u folder, the repository should report that only the folder has changes (it was replaced), but the file is already updated. Somehow, this can be misleading, even more if users are not very SVN-experimented. Best Regards, Florin On 30.09.2013 12:54, Stefan Sperling wrote: On Mon, Sep 30, 2013 at 10:58:35AM +0300, Florin Avram wrote: Hi, I've found a strange behavior in the situation described below and wanted to let you know - I think there could be an issue or a need of improvement (don't know what exactly). Subversion: 1.8.x, 1.7.x. The situation is as follows (the minimum necessary to reproduce the issue): - have a working copy with a folder and a file inside the folder; - replace the folder and commit: svn delete folder/file svn delete --keep-local folder svn add folder (consider it as a new folder) svn commit folder (both folder and file) make new file inside folder svn add folder/file svn commit folder/file - now, in another working copy: svn status -u- reports folder as replaced and file as deleted svn update folder/file - svn indicates that file was updated fine svn statsus -u - again, both folder and file are reported as previously (replaced and deleted) Repeating the file update and svn status goes on and on as file updated correctly and file reported as deleted again. Only after updating the folder everything works fine. My question(s): - is this OK to happen like this? Yes, absolutely. The 'svn update folder/file' step creates a mixed-revision working copy (child is newer than its parent) and you then query the parent with 'status -u' so you get results for the parent, not the child. See http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.basic.in-action.mixedrevs
Re: Strange behavior after replacing directory
Stefan Sperling s...@elego.de writes: On Mon, Sep 30, 2013 at 10:58:35AM +0300, Florin Avram wrote: The situation is as follows (the minimum necessary to reproduce the issue): - have a working copy with a folder and a file inside the folder; - replace the folder and commit: svn delete folder/file svn delete --keep-local folder svn add folder (consider it as a new folder) svn commit folder (both folder and file) make new file inside folder svn add folder/file svn commit folder/file - now, in another working copy: svn status -u- reports folder as replaced and file as deleted svn update folder/file - svn indicates that file was updated fine svn statsus -u - again, both folder and file are reported as previously (replaced and deleted) Repeating the file update and svn status goes on and on as file updated correctly and file reported as deleted again. Only after updating the folder everything works fine. My question(s): - is this OK to happen like this? Yes, absolutely. The 'svn update folder/file' step creates a mixed-revision working copy (child is newer than its parent) and you then query the parent with 'status -u' so you get results for the parent, not the child. It's a bit more complicated than just mixed-revision in this case; the status display is affected by internal implementation details of the update process. The tricky bit is that the parent directory is going to be deleted and replaced and the update process will delete the children inside the parent even though those children are already up-to-date. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: Strange behavior
Am 09.08.2013 21:58, schrieb Edwin Castro: On 8/9/13 10:27 AM, John Maher wrote: And svn status returns this: C Build.bat local add, incoming add upon merge You svn add Build.bat in trunk. Later you svn add Build.bat in your branch. Subversion sees those as separate objects with individual history. I've seen this here, too. It seems to be related to a user creating a branch with the OS tools without telling SVN about it, then adding it to SVN, then porting over changes by hand, then trying to merge in more changes... To create a branch, I've learned to always do an svn copy between URLs, e.g. svn cp file:///repository/trunk file:///repository/branches/mybranch. Cheers, Ulli -- Ullrich Jans, Specialist, IT-A Phone: +49 9131 7701-6627, mailto:ullrich.j...@elektrobit.com Fax: +49 9131 7701-6333, www.elektrobit.com Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany Managing Directors: Alexander Kocher, Gregor Zink Register Court Fürth HRB 4886 Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you.
RE: Strange behavior
Thanks Bob. You have been very helpful. I didn't know that there was an html version of the book. I've been using the pdf version and haven't found a way to search that. The global ignores worked. Now I'm on to my third repository. I hate having to lose all the history I'm accumulated, but that's how it goes. Thanks again. JM -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Monday, August 12, 2013 3:33 PM To: John Maher; Edwin Castro; users@subversion.apache.org Subject: RE: Strange behavior Thanks Bob, that may be exactly what I am looking for. Something that would affect all the files without having to issue over 200 commands or build a dummy directory just for importing. Although that second suggestion provided by Andrew is definitely better than the first. I couldn't find where it discusses the global config in the book, if it does at all. And even if it does I doubt it would help because it won't tell me where to find the file. Unless there is a command to edit it. I tried a search and someone says there is a site-wide config (what I need) and a user config but not where they are. I am using Windows XP and an having a difficult time finding this file. I can't even find the name of it. If someone can provide that I could at least search for it and hope it has some clue inside as how to alter it. Search for global-ignores in the single page version of the redbook: http://svnbook.red-bean.com/en/1.7/svn-book.html Here's infor about runtime configuration: http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.advanced.confarea BOb JM -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Monday, August 12, 2013 3:02 PM To: John Maher; Edwin Castro; users@subversion.apache.org Subject: RE: Strange behavior Thanks Edwin, That's exactly what I am trying to do. I was looking for a way for the tool to accomplish this. I'd be just as glad if someone tells me it is impossible, which I suspect it may be. Otherwise there are over 200 manual operations required just to create a repository. The way some people praise subversion I would think this can be automated. But then again perhaps those are the people who use subversion for the simplest of builds. I'm not sure what you are asking for? An automated way to ignore files you don't want check in? Or are you talking about import? I believe import respects global ignores if you have them set up in your config file. BOb JM -Original Message- From: Edwin Castro [mailto:0ptikgh...@gmx.us] Sent: Monday, August 12, 2013 11:55 AM To: users@subversion.apache.org Subject: Re: Strange behavior On 8/12/13 6:17 AM, John Maher wrote: Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files. In cases like this I perform a clean operation that removes compiler generated files. I would also remove any user specific files as by definition they should not be part of the repository. -- Edwin
RE: Strange behavior
Thanks David. For the past week and a half I've been wrestling with this thing. Searching, reading, trying, back to searching. Time to switch gears but I needed to get over this hurdle. I'm now on the second repository I have to dispose of (and all the history with it) so I hope the 3rd time's the charm. Thanks again JM -Original Message- From: David Chapman [mailto:dcchap...@acm.org] Sent: Monday, August 12, 2013 3:49 PM To: John Maher Cc: users@subversion.apache.org Subject: Re: Strange behavior On 8/12/2013 12:27 PM, John Maher wrote: Thanks Bob, that may be exactly what I am looking for. Something that would affect all the files without having to issue over 200 commands or build a dummy directory just for importing. Although that second suggestion provided by Andrew is definitely better than the first. I couldn't find where it discusses the global config in the book, if it does at all. And even if it does I doubt it would help because it won't tell me where to find the file. Unless there is a command to edit it. I tried a search and someone says there is a site-wide config (what I need) and a user config but not where they are. I am using Windows XP and an having a difficult time finding this file. I can't even find the name of it. If someone can provide that I could at least search for it and hope it has some clue inside as how to alter it. First link from Google (search was windows xp subversion configuration file location, http://stackoverflow.com/questions/6310539/where-is-the-subversion-global-config-file-for-the-slik-svn-client-for-windows) sez: C:\Documents and Settings\%USERNAME%\Application Data\Subversion\config I no longer run on Windows XP, so I don't remember if this is the proper place for the file, but I have no reason to doubt it. For Windows 7 it's in: C:\Users\%USERNAME%\AppData\Roaming\Subversion\config Which I can confirm. In the config file, I have my global-ignores for Windows set to: global-ignores = *.obj *.lib *.map *.exe *.bak *.pdb *.ilk *.idb There might need to be a few more; it's been several years since I have imported existing code into my Subversion repositories. But you get the idea. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
RE: Strange behavior
An excellent alternative. I will keep this in mind.
Thanks Andrew
JM
-Original Message-
From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net]
Sent: Monday, August 12, 2013 3:52 PM
To: John Maher; users@subversion.apache.org
Subject: RE: Strange behavior
-Original Message-
From: John Maher [mailto:jo...@rotair.com]
Sent: Monday, August 12, 2013 3:27 PM
To: Bob Archer; Edwin Castro; users@subversion.apache.org
Subject: RE: Strange behavior
Thanks Bob, that may be exactly what I am looking for. Something that
would affect all the files without having to issue over 200 commands
or build a dummy directory just for importing. Although that second
suggestion provided by Andrew is definitely better than the first.
I couldn't find where it discusses the global config in the book, if
it does at all. And even if it does I doubt it would help because it
won't tell me where to find the file. Unless there is a command to
edit it. I tried a search and someone says there is a site-wide
config (what I need) and a user config but not where they are. I am
using Windows XP and an having a difficult time finding this file.
I can't even find the name of it. If someone can provide that I could
at least search for it and hope it has some clue inside as how to
alter it.
Plan B might be to use svn_load_dirs.pl:
http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/
It has a glob_ignores option, or will try to read your global-ignores from
your local svn config file.
From the script:
===
# If no glob_ignores specified, try to deduce from config file, # or use the
default below.
my $ignores_str =
'*.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store';
if ( defined $opt_glob_ignores)
{
$ignores_str = $opt_glob_ignores;
}
elsif ( -f $ENV{HOME}/.subversion/config )
{
open my $conf, $ENV{HOME}/.subversion/config;
while ($conf)
{
if ( /^global-ignores\s*=\s*(.*?)\s*$/ )
{
$ignores_str = $1;
last;
}
}
}
RE: Strange behavior
Thanks Mark, that's an excellent shortcut. JM -Original Message- From: Mark Phippard [mailto:markp...@gmail.com] Sent: Monday, August 12, 2013 4:05 PM To: John Maher Cc: Bob Archer; Edwin Castro; users@subversion.apache.org Subject: Re: Strange behavior On Mon, Aug 12, 2013 at 3:27 PM, John Maher jo...@rotair.com wrote: I couldn't find where it discusses the global config in the book, if it does at all. And even if it does I doubt it would help because it won't tell me where to find the file. Unless there is a command to edit it. I tried a search and someone says there is a site-wide config (what I need) and a user config but not where they are. I am using Windows XP and an having a difficult time finding this file. The configuration area is in the book in here: http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html The footnote links to the easiest way to find the file: %APPDATA%\Subversion Just enter that into the Windows Run dialog or the address bar of the file explorer and it will take you to the right folder where the configuration files are found. This is true for XP as well as Win 7. -- Thanks Mark Phippard http://markphip.blogspot.com/
RE: Strange behavior
Hi Thorsten A good response to a less than good post. People could take lessons from you. Actually, its been a frustrating week. Sometimes subversion accepts the wrong slash in a path, other times it does not. Sometimes it enforces case sensitivity in a url other times it does not. Follow the book on how it instructs to import a project then it becomes impossible to merge and branch. And now for the second time I must discard my repository along with all the history I've accumulated. Yes you can say frustrating, bordering on maddening. I got a good laugh from: Of course it can, just copy your 200 commands line by line one after another into a batch file. JM -Original Message- From: Thorsten Schöning [mailto:tschoen...@am-soft.de] Sent: Monday, August 12, 2013 4:43 PM To: users@subversion.apache.org Subject: Re: Strange behavior Guten Tag John Maher, am Montag, 12. August 2013 um 20:57 schrieben Sie: Otherwise there are over 200 manual operations required just to create a repository. As you mentioned you are still working on Windows XP, you are aware of TortoiseSVN, aren't you? There shouldn't be the need to run any command yourself as Tortoise is able to create repos and act as a subversion client. The way some people praise subversion I would think this can be automated. Of course it can, just copy your 200 commands line by line one after another into a batch file. ;-) But then again perhaps those are the people who use subversion for the simplest of builds. Frustrating day, wasn't it? :-) 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: Strange behavior
One thing I forgot to mention is that yes, I know of Tortoise. I started with that. It works good for the most commonly used stuff, but falls short as a complete solution. So I really need to know how the real tool works. That is why I am struggling with the command line. JM -Original Message- From: Thorsten Schöning [mailto:tschoen...@am-soft.de] Sent: Monday, August 12, 2013 4:43 PM To: users@subversion.apache.org Subject: Re: Strange behavior Guten Tag John Maher, am Montag, 12. August 2013 um 20:57 schrieben Sie: Otherwise there are over 200 manual operations required just to create a repository. As you mentioned you are still working on Windows XP, you are aware of TortoiseSVN, aren't you? There shouldn't be the need to run any command yourself as Tortoise is able to create repos and act as a subversion client. The way some people praise subversion I would think this can be automated. Of course it can, just copy your 200 commands line by line one after another into a batch file. ;-) But then again perhaps those are the people who use subversion for the simplest of builds. Frustrating day, wasn't it? :-) 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: Strange behavior
Guten Tag John Maher, am Dienstag, 13. August 2013 um 15:39 schrieben Sie: Follow the book on how it instructs to import a project then it becomes impossible to merge and branch. Branching is always possible and always equally cheap regardless of what you did before, because it breaks down to a cheap copy operation with preserving history. The only thing which may cost time is updating/checking the new branch out. If you have merge problems because of your tests or whatever one solution may be just recording merge info. This way you can move and copy and delete things in any way you like and make subversion think that those changes are already applied to a selected directory without really applying them, meaning you won't get any merge conflicts now or later from the revisions you recorded as already merged. This may prevent re-creating your repo and losing history. http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.blockchanges 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: Strange behavior
-Original Message- From: John Maher [mailto:jo...@rotair.com] Sent: Tuesday, August 13, 2013 9:40 AM To: Thorsten Schöning; users@subversion.apache.org Subject: RE: Strange behavior Hi Thorsten A good response to a less than good post. People could take lessons from you. Actually, its been a frustrating week. Sometimes subversion accepts the wrong slash in a path, other times it does not. Sometimes it enforces case sensitivity in a url other times it does not. Sounds like normal windows-unix interaction issues. They're not that bad if you have experience with UNIX systems. In the Windows CMD shell, if you wrap your pathnames in double quotes, you can use forward slashes instead of backslashes for directory separators, e.g. dir /s c:/program files/subversion, which helps when feeding paths between CMD commands and svn commands. Follow the book on how it instructs to import a project then it becomes impossible to merge and branch. That's odd. Very odd. It's much more likely that you're not grokking some paradigm or missed a step when creating the branch. You might want to post your branch/merge test process (especially the commands) and have the list vet it. And now for the second time I must discard my repository along with all the history I've accumulated. Yes you can say frustrating, bordering on maddening. Why? If you have a good initial import checked in, then create a new test branch, or even roll trunk back to the initial import. Example: Revision 10 of /trunk is your 200 commands to import the initial baseline. 1. Create a new test branch from rev 10: svn copy svn://server/trunk svn://server/branches/new_test_branch@10 Or if you want to roll trunk back to rev 10: 1. svn rm svn://server/trunk 2. svn copy svn://server/trunk@10 svn://server/trunk 3. create new test branch: svn copy svn://server/trunk svn://server/branches/new_test_branch The original trunk branch (with revisions 11+) is still available via peg revisions, but peg revisions are a topic for later. Or if you really want a fresh repo, then you can use 'svn export -r' to export the initial working baseline and then import those files into your new test repository. Meaning, if revision 10 represents your initial 200 commands of importing files, then export revision 10 using 'svn export -r 10 ...'. This lets you start a new repo without having to re-do the import from scratch. I would tell you about 'svnadmin dump', but given your current mental state, that's probably not a good idea. I got a good laugh from: Of course it can, just copy your 200 commands line by line one after another into a batch file. I know it was a humorous comment, but... Anyway, dealing with new software with new paradigms/assumptions can be very frustrating (e.g. going from ClearCase to 1.3 SVN, *g*) but you need to take a step back and relax. Importing and branching and merging in svn 1.8 really isn't (shouldn't be) that difficult. Plus, svn 1.8 is pretty robust and a mature product, so you shouldn't be fighting with it that much. Good luck, and keep up the perseverance. That which doesn't kill you, probably leaves you crippled and weak (or something to that effect.)
Re: Strange behavior
On Tue, Aug 13, 2013 at 4:12 PM, John Maher jo...@rotair.com wrote: Thanks Ryan. I learned a lot from your reply. Namely the global-ignores are really local global-ignores and I have to copy the config file over to anyone who may import. As of version 1.8 (for the svn client), there is a new feature called Repository Dictated Configuration [1], which you can use to set a global-ignores that will be applied by all standard 1.8 clients. It works by setting an svn:global-ignores property on a directory in your repository, which then applies to the entire subtree under that directory. However, I'm not sure if that feature applies to 'svn import' (because it doesn't have a working copy). I guess someone will have to try it :-). [1] http://subversion.apache.org/docs/release-notes/1.8.html#repos-dictated-config -- Johan
RE: Strange behavior
Thanks Johan, I'll have to try it. -Original Message- From: Johan Corveleyn [mailto:jcor...@gmail.com] Sent: Tuesday, August 13, 2013 11:42 AM To: John Maher Cc: Ryan Schmidt; Subversion Users Subject: Re: Strange behavior On Tue, Aug 13, 2013 at 4:12 PM, John Maher jo...@rotair.com wrote: Thanks Ryan. I learned a lot from your reply. Namely the global-ignores are really local global-ignores and I have to copy the config file over to anyone who may import. As of version 1.8 (for the svn client), there is a new feature called Repository Dictated Configuration [1], which you can use to set a global-ignores that will be applied by all standard 1.8 clients. It works by setting an svn:global-ignores property on a directory in your repository, which then applies to the entire subtree under that directory. However, I'm not sure if that feature applies to 'svn import' (because it doesn't have a working copy). I guess someone will have to try it :-). [1] http://subversion.apache.org/docs/release-notes/1.8.html#repos-dictated-config -- Johan
RE: Strange behavior
Thanks Andrew, I started going through your steps and discovered something. My repository is called either iERP85_v2 or iERP85_V2. Visual SVN reports the latter but the former works with the client. Don't know which nor why one product chooses one over the other. My mistake was assuming I make a mistake with the repository. The mistake I actually made was trusting visual svn server. Although svn did report the smaller v it can be difficult to notice. So I created two branches for two new features I am working on. I'll see how they go. Thanks again JM -Original Message- From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net] Sent: Tuesday, August 13, 2013 10:27 AM To: John Maher; users@subversion.apache.org Subject: RE: Strange behavior -Original Message- From: John Maher [mailto:jo...@rotair.com] Sent: Tuesday, August 13, 2013 9:40 AM To: Thorsten Schöning; users@subversion.apache.org Subject: RE: Strange behavior Hi Thorsten A good response to a less than good post. People could take lessons from you. Actually, its been a frustrating week. Sometimes subversion accepts the wrong slash in a path, other times it does not. Sometimes it enforces case sensitivity in a url other times it does not. Sounds like normal windows-unix interaction issues. They're not that bad if you have experience with UNIX systems. In the Windows CMD shell, if you wrap your pathnames in double quotes, you can use forward slashes instead of backslashes for directory separators, e.g. dir /s c:/program files/subversion, which helps when feeding paths between CMD commands and svn commands. Follow the book on how it instructs to import a project then it becomes impossible to merge and branch. That's odd. Very odd. It's much more likely that you're not grokking some paradigm or missed a step when creating the branch. You might want to post your branch/merge test process (especially the commands) and have the list vet it. And now for the second time I must discard my repository along with all the history I've accumulated. Yes you can say frustrating, bordering on maddening. Why? If you have a good initial import checked in, then create a new test branch, or even roll trunk back to the initial import. Example: Revision 10 of /trunk is your 200 commands to import the initial baseline. 1. Create a new test branch from rev 10: svn copy svn://server/trunk svn://server/branches/new_test_branch@10 Or if you want to roll trunk back to rev 10: 1. svn rm svn://server/trunk 2. svn copy svn://server/trunk@10 svn://server/trunk 3. create new test branch: svn copy svn://server/trunk svn://server/branches/new_test_branch The original trunk branch (with revisions 11+) is still available via peg revisions, but peg revisions are a topic for later. Or if you really want a fresh repo, then you can use 'svn export -r' to export the initial working baseline and then import those files into your new test repository. Meaning, if revision 10 represents your initial 200 commands of importing files, then export revision 10 using 'svn export -r 10 ...'. This lets you start a new repo without having to re-do the import from scratch. I would tell you about 'svnadmin dump', but given your current mental state, that's probably not a good idea. I got a good laugh from: Of course it can, just copy your 200 commands line by line one after another into a batch file. I know it was a humorous comment, but... Anyway, dealing with new software with new paradigms/assumptions can be very frustrating (e.g. going from ClearCase to 1.3 SVN, *g*) but you need to take a step back and relax. Importing and branching and merging in svn 1.8 really isn't (shouldn't be) that difficult. Plus, svn 1.8 is pretty robust and a mature product, so you shouldn't be fighting with it that much. Good luck, and keep up the perseverance. That which doesn't kill you, probably leaves you crippled and weak (or something to that effect.)
RE: Strange behavior
Thanks for your help, but I still do not know how to get this to work. Perhaps I should give a little background. The project that I mentioned in my original post was a test project created just to learn how to get subversion to work. The production code that I wish to put in one repository resides in 62 directories that have over 2000 files in them of which only some of them can be included otherwise merging becomes impossible. The whole point of this exercise is to get merging to work since it causes unnecessary difficultly to try to separate new features with bug fixes in a single branch. But this is all I could get to work. Unfortunately no matter how much I read (I read the first half of the book twice) and how much I checkout and commit the tool fails to work for me. And the only reason I have been complaining about the documentation is hoping to point out areas where it is very unclear and misleading. Anyone who knows how to use the tool will never catch on to the poorly written areas of the documentation, they are biased. You NEED someone who doesn't know how to use the tool to indicate areas that need to be addressed. But since no one here is interested to maintaining good documentation and are more interested in hunting out any obscured word they can find just to say look, it is right!! it seems best if I never, ever point out any flaws in the documentation. I will just selfishly concern myself with my own problems, it seems all will get along better that way. Now the two suggestions I have are auto properties and in place import. The links provided do not relate to my situation. The provided link indicates properties that get set DURING the import. I need to ignore files BEFORE the import. Like I originally stated, I need to import SOME files. Importing compiler generated files OR user settings causes problem and makes merging impossible thereby defeating some of the benefits of using subversion. If this method will solve this problem can you provide me with a link indicating how to do this? I can not find anything in the book nor the provided link. If you could give me some keywords to search for that would help also. I tried searching and all I find is questions relating to different actions. I looked at the import command in the book and with the svn help command and could not see how to use the svn:ignore. The import-in-place command works on a single file. That would indicate I would need to issue the command hundreds of times. Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files. JM -Original Message- From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] Sent: Friday, August 09, 2013 4:17 PM To: John Maher Cc: Subversion Users Subject: Re: Strange behavior Remember to Reply All so that your message goes to the mailing list too, not just to me. On Aug 9, 2013, at 14:59, John Maher wrote: Thanks for your reply. I appreciate informing me that subversion is robust. I was concerned it was getting corrupted by the strange behavior. Plus you've also helped by telling me that the ignore property does not mean ignore, it means sometimes ignore. On page 68 of the book it explains that the ignore property is used to eliminate files from svn status. But your explanation matches my observations, thank you. The book is wrong again. I tried to delete the files from the repository with svn delete, but that failed because they were not part of the current revision. So it seems that I have to delete the repository and create it again (for the 3rd time). Does import work with the ignore property? It mentions it in the help, but I do not know if the help is wrong. If properties need to be applied to a working directory how do I use them with the import command BEFORE a working copy exists?. I followed the instructions in the book, created a repository and it came out all wrong, again. Can someone tell me how to get code files into the repository and stop the compiler generated files and directories? Thanks JM Page 68 of the PDF version of the book is within the section Ignoring Unversioned Items, but the items you're talking about are versioned, not unversioned. svn import will obey your svn autoprops: http://svnbook.red-bean.com/en/1.7/svn.advanced.props.html#svn.advanced.props.auto But I often prefer to avoid the svn import command and do an in-place import instead: http://subversion.apache.org/faq.html#in-place-import This affords you the opportunity to be more selective about what you import and to add properties before committing.
Re: Strange behavior
On 8/12/13 6:17 AM, John Maher wrote: Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files. In cases like this I perform a clean operation that removes compiler generated files. I would also remove any user specific files as by definition they should not be part of the repository. -- Edwin
RE: Strange behavior
-Original Message- From: John Maher [mailto:jo...@rotair.com] Sent: Monday, August 12, 2013 10:18 AM To: Ryan Schmidt Cc: Subversion Users Subject: RE: Strange behavior Thanks for your help, but I still do not know how to get this to work. Perhaps I should give a little background. The project that I mentioned in my original post was a test project created just to learn how to get subversion to work. The production code that I wish to put in one repository resides in 62 directories that have over 2000 files in them of which only some of them can be included otherwise merging becomes impossible. The whole point of this exercise is to get merging to work since it causes unnecessary difficultly to try to separate new features with bug fixes in a single branch. But this is all I could get to work. Unfortunately no matter how much I read (I read the first half of the book twice) and how much I checkout and commit the tool fails to work for me. You're overthinking this. You can use OS level commands to trim down the files to import. Copy the files to a temp directory, delete the files you don't want imported, and then run 'svn import' on the tmp dir. Even if you have mistakes in the import, you can use 'svn rm' and 'svn add' to clean things up. It would be nice if you could pass 'svn import' a list of filenames/regexes to include or exclude, but modern shells already have the tools to filter and delete files, so there's little need to add those wheels to 'svn import'. Especially since the import is normally a one-time event. Are you using 'svn import' multiple times? (Such as to create additional branches of the code?) If so, that would be bad, as in wrong paradigm/workflow. As for branching, here's the short version for the 1.8 svn client: 0) Use 'svn import' to create the initial baseline, say /trunk. then 1) Create the branch: 'svn copy svn:/server/trunk svn:/server/branches/foo.2.0.0' 2) Create branch workspace: cd /myworkspaces svn co svn:/server/branches/foo.2.0.0' cd foo.2.0.0 3) Work on foo.2.0.0 3.1) 'svn add' to add new files (svn:ignore will help here.) 3.2) 'svn ci' to commit the files 3.2) Periodically merge trunk changes up to foo.2.0.0: svn merge ^/trunk Note: makes sure your foo.2.0.0 changes are checked in before merging up from trunk, 'svn status' When foo.2.0.0 is done, first merge trunk up to foo.2.0.0 to make sure that foo.2.0.0 has the current trunk changes 4) 'svn merge ^/trunk' 4.1) Resolve any conflicts. Now merge foo.2.0.0 down to trunk. 5) Create a clean merge workspace cd /myworkspaces 'svn co svn:/server/trunk' cd trunk Note: if you are reusing a workspace, then 'svn status' and 'svn update' to make sure it's clean and ready for a merge. 6) 'svn merge ^/branches/foo.2.0.0' 6.1) Resolve any conflicts. 7) 'svn ci'
RE: Strange behavior
Thanks Edwin, That's exactly what I am trying to do. I was looking for a way for the tool to accomplish this. I'd be just as glad if someone tells me it is impossible, which I suspect it may be. Otherwise there are over 200 manual operations required just to create a repository. The way some people praise subversion I would think this can be automated. But then again perhaps those are the people who use subversion for the simplest of builds. JM -Original Message- From: Edwin Castro [mailto:0ptikgh...@gmx.us] Sent: Monday, August 12, 2013 11:55 AM To: users@subversion.apache.org Subject: Re: Strange behavior On 8/12/13 6:17 AM, John Maher wrote: Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files. In cases like this I perform a clean operation that removes compiler generated files. I would also remove any user specific files as by definition they should not be part of the repository. -- Edwin
RE: Strange behavior
Thanks Edwin, That's exactly what I am trying to do. I was looking for a way for the tool to accomplish this. I'd be just as glad if someone tells me it is impossible, which I suspect it may be. Otherwise there are over 200 manual operations required just to create a repository. The way some people praise subversion I would think this can be automated. But then again perhaps those are the people who use subversion for the simplest of builds. I'm not sure what you are asking for? An automated way to ignore files you don't want check in? Or are you talking about import? I believe import respects global ignores if you have them set up in your config file. BOb JM -Original Message- From: Edwin Castro [mailto:0ptikgh...@gmx.us] Sent: Monday, August 12, 2013 11:55 AM To: users@subversion.apache.org Subject: Re: Strange behavior On 8/12/13 6:17 AM, John Maher wrote: Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files. In cases like this I perform a clean operation that removes compiler generated files. I would also remove any user specific files as by definition they should not be part of the repository. -- Edwin
RE: Strange behavior
Thanks for the quick merge lesson. I would need to use the same directory for the branch as the trunk since there is a rather large infrastructure required to run the project (It is an ERP application). So I would plan on using switch. As long there are no hidden gotchas I should be OK. -Original Message- From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net] Sent: Monday, August 12, 2013 1:39 PM To: John Maher Cc: Subversion Users Subject: RE: Strange behavior -Original Message- From: John Maher [mailto:jo...@rotair.com] Sent: Monday, August 12, 2013 10:18 AM To: Ryan Schmidt Cc: Subversion Users Subject: RE: Strange behavior Thanks for your help, but I still do not know how to get this to work. Perhaps I should give a little background. The project that I mentioned in my original post was a test project created just to learn how to get subversion to work. The production code that I wish to put in one repository resides in 62 directories that have over 2000 files in them of which only some of them can be included otherwise merging becomes impossible. The whole point of this exercise is to get merging to work since it causes unnecessary difficultly to try to separate new features with bug fixes in a single branch. But this is all I could get to work. Unfortunately no matter how much I read (I read the first half of the book twice) and how much I checkout and commit the tool fails to work for me. You're overthinking this. You can use OS level commands to trim down the files to import. Copy the files to a temp directory, delete the files you don't want imported, and then run 'svn import' on the tmp dir. Even if you have mistakes in the import, you can use 'svn rm' and 'svn add' to clean things up. It would be nice if you could pass 'svn import' a list of filenames/regexes to include or exclude, but modern shells already have the tools to filter and delete files, so there's little need to add those wheels to 'svn import'. Especially since the import is normally a one-time event. Are you using 'svn import' multiple times? (Such as to create additional branches of the code?) If so, that would be bad, as in wrong paradigm/workflow. As for branching, here's the short version for the 1.8 svn client: 0) Use 'svn import' to create the initial baseline, say /trunk. then 1) Create the branch: 'svn copy svn:/server/trunk svn:/server/branches/foo.2.0.0' 2) Create branch workspace: cd /myworkspaces svn co svn:/server/branches/foo.2.0.0' cd foo.2.0.0 3) Work on foo.2.0.0 3.1) 'svn add' to add new files (svn:ignore will help here.) 3.2) 'svn ci' to commit the files 3.2) Periodically merge trunk changes up to foo.2.0.0: svn merge ^/trunk Note: makes sure your foo.2.0.0 changes are checked in before merging up from trunk, 'svn status' When foo.2.0.0 is done, first merge trunk up to foo.2.0.0 to make sure that foo.2.0.0 has the current trunk changes 4) 'svn merge ^/trunk' 4.1) Resolve any conflicts. Now merge foo.2.0.0 down to trunk. 5) Create a clean merge workspace cd /myworkspaces 'svn co svn:/server/trunk' cd trunk Note: if you are reusing a workspace, then 'svn status' and 'svn update' to make sure it's clean and ready for a merge. 6) 'svn merge ^/branches/foo.2.0.0' 6.1) Resolve any conflicts. 7) 'svn ci'
RE: Strange behavior
Thanks Bob, that may be exactly what I am looking for. Something that would affect all the files without having to issue over 200 commands or build a dummy directory just for importing. Although that second suggestion provided by Andrew is definitely better than the first. I couldn't find where it discusses the global config in the book, if it does at all. And even if it does I doubt it would help because it won't tell me where to find the file. Unless there is a command to edit it. I tried a search and someone says there is a site-wide config (what I need) and a user config but not where they are. I am using Windows XP and an having a difficult time finding this file. I can't even find the name of it. If someone can provide that I could at least search for it and hope it has some clue inside as how to alter it. JM -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Monday, August 12, 2013 3:02 PM To: John Maher; Edwin Castro; users@subversion.apache.org Subject: RE: Strange behavior Thanks Edwin, That's exactly what I am trying to do. I was looking for a way for the tool to accomplish this. I'd be just as glad if someone tells me it is impossible, which I suspect it may be. Otherwise there are over 200 manual operations required just to create a repository. The way some people praise subversion I would think this can be automated. But then again perhaps those are the people who use subversion for the simplest of builds. I'm not sure what you are asking for? An automated way to ignore files you don't want check in? Or are you talking about import? I believe import respects global ignores if you have them set up in your config file. BOb JM -Original Message- From: Edwin Castro [mailto:0ptikgh...@gmx.us] Sent: Monday, August 12, 2013 11:55 AM To: users@subversion.apache.org Subject: Re: Strange behavior On 8/12/13 6:17 AM, John Maher wrote: Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files. In cases like this I perform a clean operation that removes compiler generated files. I would also remove any user specific files as by definition they should not be part of the repository. -- Edwin
RE: Strange behavior
Thanks Bob, that may be exactly what I am looking for. Something that would affect all the files without having to issue over 200 commands or build a dummy directory just for importing. Although that second suggestion provided by Andrew is definitely better than the first. I couldn't find where it discusses the global config in the book, if it does at all. And even if it does I doubt it would help because it won't tell me where to find the file. Unless there is a command to edit it. I tried a search and someone says there is a site-wide config (what I need) and a user config but not where they are. I am using Windows XP and an having a difficult time finding this file. I can't even find the name of it. If someone can provide that I could at least search for it and hope it has some clue inside as how to alter it. Search for global-ignores in the single page version of the redbook: http://svnbook.red-bean.com/en/1.7/svn-book.html Here's infor about runtime configuration: http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.advanced.confarea BOb JM -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Monday, August 12, 2013 3:02 PM To: John Maher; Edwin Castro; users@subversion.apache.org Subject: RE: Strange behavior Thanks Edwin, That's exactly what I am trying to do. I was looking for a way for the tool to accomplish this. I'd be just as glad if someone tells me it is impossible, which I suspect it may be. Otherwise there are over 200 manual operations required just to create a repository. The way some people praise subversion I would think this can be automated. But then again perhaps those are the people who use subversion for the simplest of builds. I'm not sure what you are asking for? An automated way to ignore files you don't want check in? Or are you talking about import? I believe import respects global ignores if you have them set up in your config file. BOb JM -Original Message- From: Edwin Castro [mailto:0ptikgh...@gmx.us] Sent: Monday, August 12, 2013 11:55 AM To: users@subversion.apache.org Subject: Re: Strange behavior On 8/12/13 6:17 AM, John Maher wrote: Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files. In cases like this I perform a clean operation that removes compiler generated files. I would also remove any user specific files as by definition they should not be part of the repository. -- Edwin
Re: Strange behavior
On 8/12/13 10:57 AM, John Maher wrote: But then again perhaps those are the people who use subversion for the simplest of builds. At my previous employer I was partly responsible for a codebase in subversion whose trunk was 2+ GB large. The codebase included over 1400 C#, C++, SQL, and WiX projects. I think many of us have very complicated builds. We simply choose to use the correct tool for the job. Working on Windows I wrote many PowerShell scripts to help me manage bulk operations. I have no evidence but I suspect most of us have lots of experience working with very large codebases in subversion. Suggesting that we have the simplest of builds comes across as elitist which is odd coming from an obvious beginner. There is clear evidence that there's a cognitive mismatch between your current understanding and how subversion is intended to be used. We're here to help you but that help will come these discussions occur with respect. Sometimes it is better to present the experts with the problem you are trying to solve including how you've attempted to solve it, accepting the possibility that your current approach may not be the best approach. Seems like I keep hearing you're doing it wrong from the list and you keep responding with I don't care, how do accomplish this anyway. I don't think that's a good attitude to take. -- Edwin
Re: Strange behavior
On 8/12/2013 12:27 PM, John Maher wrote: Thanks Bob, that may be exactly what I am looking for. Something that would affect all the files without having to issue over 200 commands or build a dummy directory just for importing. Although that second suggestion provided by Andrew is definitely better than the first. I couldn't find where it discusses the global config in the book, if it does at all. And even if it does I doubt it would help because it won't tell me where to find the file. Unless there is a command to edit it. I tried a search and someone says there is a site-wide config (what I need) and a user config but not where they are. I am using Windows XP and an having a difficult time finding this file. I can't even find the name of it. If someone can provide that I could at least search for it and hope it has some clue inside as how to alter it. First link from Google (search was windows xp subversion configuration file location, http://stackoverflow.com/questions/6310539/where-is-the-subversion-global-config-file-for-the-slik-svn-client-for-windows) sez: C:\Documents and Settings\%USERNAME%\Application Data\Subversion\config I no longer run on Windows XP, so I don't remember if this is the proper place for the file, but I have no reason to doubt it. For Windows 7 it's in: C:\Users\%USERNAME%\AppData\Roaming\Subversion\config Which I can confirm. In the config file, I have my global-ignores for Windows set to: global-ignores = *.obj *.lib *.map *.exe *.bak *.pdb *.ilk *.idb There might need to be a few more; it's been several years since I have imported existing code into my Subversion repositories. But you get the idea. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
RE: Strange behavior
-Original Message-
From: John Maher [mailto:jo...@rotair.com]
Sent: Monday, August 12, 2013 3:27 PM
To: Bob Archer; Edwin Castro; users@subversion.apache.org
Subject: RE: Strange behavior
Thanks Bob, that may be exactly what I am looking for. Something that
would affect all the files without having to issue over 200 commands or
build a dummy directory just for importing. Although that second
suggestion provided by Andrew is definitely better than the first.
I couldn't find where it discusses the global config in the book, if it
does at all. And even if it does I doubt it would help because it
won't tell me where to find the file. Unless there is a command to
edit it. I tried a search and someone says there is a site-wide config
(what I need) and a user config but not where they are. I am using
Windows XP and an having a difficult time finding this file.
I can't even find the name of it. If someone can provide that I could
at least search for it and hope it has some clue inside as how to alter
it.
Plan B might be to use svn_load_dirs.pl:
http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/
It has a glob_ignores option, or will try to read your global-ignores from
your local svn config file.
From the script:
===
# If no glob_ignores specified, try to deduce from config file,
# or use the default below.
my $ignores_str =
'*.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store';
if ( defined $opt_glob_ignores)
{
$ignores_str = $opt_glob_ignores;
}
elsif ( -f $ENV{HOME}/.subversion/config )
{
open my $conf, $ENV{HOME}/.subversion/config;
while ($conf)
{
if ( /^global-ignores\s*=\s*(.*?)\s*$/ )
{
$ignores_str = $1;
last;
}
}
}
Re: Strange behavior
On Mon, Aug 12, 2013 at 4:17 PM, John Maher jo...@rotair.com wrote: ... And the only reason I have been complaining about the documentation is hoping to point out areas where it is very unclear and misleading. Anyone who knows how to use the tool will never catch on to the poorly written areas of the documentation, they are biased. You NEED someone who doesn't know how to use the tool to indicate areas that need to be addressed. But since no one here is interested to maintaining good documentation and are more interested in hunting out any obscured word they can find just to say look, it is right!! it seems best if I never, ever point out any flaws in the documentation. I will just selfishly concern myself with my own problems, it seems all will get along better that way. But since no one here is interested to maintaining good documentation ...? Oh come on. Of course we want good documentation, and feedback to help improve it is more than welcome. But give the people on this list some credit too, please. Have you read the very first response you got, from Ryan Schmidt, pointing you to the website of the book, where your feedback would be most welcome? Also, please keep in mind that the most useful feedback comes in the form of concrete suggestions, or pointing out specific shortcomings. If you say I didn't find anything about X, and someone replies it's on page Y, then the feedback loop is closed. If you want your not finding about X to be any further useful book feedback, you'll have to argue why your non-finding is a book problem (rather than an oops, I looked at the wrong section problem), and that it should be explained or pointed to on page Z, or wherever you expected to find info about it. -- Johan
Re: Strange behavior
On Mon, Aug 12, 2013 at 3:27 PM, John Maher jo...@rotair.com wrote: I couldn't find where it discusses the global config in the book, if it does at all. And even if it does I doubt it would help because it won't tell me where to find the file. Unless there is a command to edit it. I tried a search and someone says there is a site-wide config (what I need) and a user config but not where they are. I am using Windows XP and an having a difficult time finding this file. The configuration area is in the book in here: http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html The footnote links to the easiest way to find the file: %APPDATA%\Subversion Just enter that into the Windows Run dialog or the address bar of the file explorer and it will take you to the right folder where the configuration files are found. This is true for XP as well as Win 7. -- Thanks Mark Phippard http://markphip.blogspot.com/
RE: Strange behavior
I apologize. It was wrong to say no one here is interested . . . Some people are uninterested. Some are interested. Some are extremely helpful. Some can be very egotistical. Just like the real world, you get a mix of good and less than good. I should've never responded like that to a group because of an apple that I did not agree with. Being frustrated with this product (no excuse) add to that critisim when I try to help (maybe small excuse there) equals my reason, though it is not a good one. There's inconsistencies with the svn help command also. Maybe in the future I'll help with the documentation. But when you get a free product, and want to give back then take flak when you think you are helping it kinda kills the urge to help. But I never should've used an absolute like that. Thank you for pointing it out Johan and pointing it out in a polite way instead of condescending. -Original Message- From: Johan Corveleyn [mailto:jcor...@gmail.com] Sent: Monday, August 12, 2013 3:54 PM To: John Maher Cc: Ryan Schmidt; Subversion Users Subject: Re: Strange behavior On Mon, Aug 12, 2013 at 4:17 PM, John Maher jo...@rotair.com wrote: ... And the only reason I have been complaining about the documentation is hoping to point out areas where it is very unclear and misleading. Anyone who knows how to use the tool will never catch on to the poorly written areas of the documentation, they are biased. You NEED someone who doesn't know how to use the tool to indicate areas that need to be addressed. But since no one here is interested to maintaining good documentation and are more interested in hunting out any obscured word they can find just to say look, it is right!! it seems best if I never, ever point out any flaws in the documentation. I will just selfishly concern myself with my own problems, it seems all will get along better that way. But since no one here is interested to maintaining good documentation ...? Oh come on. Of course we want good documentation, and feedback to help improve it is more than welcome. But give the people on this list some credit too, please. Have you read the very first response you got, from Ryan Schmidt, pointing you to the website of the book, where your feedback would be most welcome? Also, please keep in mind that the most useful feedback comes in the form of concrete suggestions, or pointing out specific shortcomings. If you say I didn't find anything about X, and someone replies it's on page Y, then the feedback loop is closed. If you want your not finding about X to be any further useful book feedback, you'll have to argue why your non-finding is a book problem (rather than an oops, I looked at the wrong section problem), and that it should be explained or pointed to on page Z, or wherever you expected to find info about it. -- Johan
Re: Strange behavior
On Aug 12, 2013, at 14:52, Andrew Reedick wrote:
Plan B might be to use svn_load_dirs.pl:
http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/
It has a glob_ignores option, or will try to read your global-ignores from
your local svn config file.
From the script:
===
# If no glob_ignores specified, try to deduce from config file,
# or use the default below.
my $ignores_str =
'*.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store';
if ( defined $opt_glob_ignores)
{
$ignores_str = $opt_glob_ignores;
}
elsif ( -f $ENV{HOME}/.subversion/config )
{
open my $conf, $ENV{HOME}/.subversion/config;
while ($conf)
{
if ( /^global-ignores\s*=\s*(.*?)\s*$/ )
{
$ignores_str = $1;
last;
}
}
}
svn_load_dirs is for loading multiple versions of an old project into a version
control system for the first time. The user hasn't said anything about wanting
to do that so I don't think there's any need to jump to svn_load_dirs. It seems
like its glob_ignores just does what the built-in global-ignores already does.
Re: Strange behavior
Guten Tag John Maher, am Montag, 12. August 2013 um 20:57 schrieben Sie: Otherwise there are over 200 manual operations required just to create a repository. As you mentioned you are still working on Windows XP, you are aware of TortoiseSVN, aren't you? There shouldn't be the need to run any command yourself as Tortoise is able to create repos and act as a subversion client. The way some people praise subversion I would think this can be automated. Of course it can, just copy your 200 commands line by line one after another into a batch file. ;-) But then again perhaps those are the people who use subversion for the simplest of builds. Frustrating day, wasn't it? :-) 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: Strange behavior
On Aug 12, 2013, at 09:17, John Maher wrote: Thanks for your help, but I still do not know how to get this to work. Perhaps I should give a little background. The project that I mentioned in my original post was a test project created just to learn how to get subversion to work. The production code that I wish to put in one repository resides in 62 directories that have over 2000 files in them of which only some of them can be included otherwise merging becomes impossible. The whole point of this exercise is to get merging to work since it causes unnecessary difficultly to try to separate new features with bug fixes in a single branch. But this is all I could get to work. Unfortunately no matter how much I read (I read the first half of the book twice) and how much I checkout and commit the tool fails to work for me. I'll let others address your merging questions, since I read the book before Subversion 1.5 was released, when merge tracking was introduced, which has simplified merging considerably. And the only reason I have been complaining about the documentation is hoping to point out areas where it is very unclear and misleading. Anyone who knows how to use the tool will never catch on to the poorly written areas of the documentation, they are biased. You NEED someone who doesn't know how to use the tool to indicate areas that need to be addressed. I totally agree, and please continue doing this. I did originally learn Subversion by reading the book, so that was the basis for my praise of it, but I have learned many more things by reading years of messages on this list so sometimes it's hard for me to recall where a particular bit of knowledge came from. Now the two suggestions I have are auto properties and in place import. The links provided do not relate to my situation. I think when I said auto-props, I meant global-ignores. Sorry about that. They're related in that they're both considered when importing. I think I see why I said that: you wrote: Does import work with the ignore property? It mentions it in the help, but I do not know if the help is wrong. If properties need to be applied to a working directory how do I use them with the import command BEFORE a working copy exists? I was confusing the svn:ignore property with the global-ignores config file setting. The svn:ignore property is applied to a directory so that files inside it might be ignored (and which affects all users who might check out a working copy of this directory), and yes, that has to happen in a working copy. The global-ignores setting in your Subversion config file has a similar function but affects all working copies and import actions you perform, regardless what server is involved, and affects only you. The provided link indicates properties that get set DURING the import. I need to ignore files BEFORE the import. Like I originally stated, I need to import SOME files. Importing compiler generated files OR user settings causes problem and makes merging impossible thereby defeating some of the benefits of using subversion. If this method will solve this problem can you provide me with a link indicating how to do this? I can not find anything in the book nor the provided link. If you could give me some keywords to search for that would help also. I tried searching and all I find is questions relating to different actions. I looked at the import command in the book and with the svn help command and could not see how to use the svn:ignore. The import-in-place command works on a single file. That would indicate I would need to issue the command hundreds of times. Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files. The in-place import does not operate on a single file; it is a procedure for importing any number of items within a directory. The example in the FAQ showed how to do an in-place import of four files in /etc. I'll try to explain in more detail. Let's say you have a directory of original files, and a repository you want to import them into. You want to import some files but not others. Maybe you want to set properties on some files, such as MIME types or line ending styles. == Normal Import == With a normal import, you run a single command svn import and the contents of the directory are imported into the repository. While doing so, Subversion considers your global-ignores (to decide which files not to import) and your auto-props (to decide what properties to apply to files that are imported), but there is no opportunity to inspect the results of that consideration before the files are committed to the repository. Once a normal import is completed, your original directory is untouched. To get a working copy that you can perform additional Subversion
Re: Strange behavior
On Aug 9, 2013, at 12:27, John Maher wrote: One of the biggest issues is why does it not ignore files I tell it to ignore? The patterns you specify in svn:ignore properties are only so that Subversion does not suggest those files to be added to the repository. For example, if you run svn status and it tells you some files are unversioned (status ?), but you never intend to version them, then you add those files to svn:ignore so that Subversion won't tell you about them anymore. But if you've already added the files to your repository, as seems to be the case here, then svn:ignore is no longer applicable. Is subversion extremely fragile? Is there a way to fix it? I would call Subversion extremely robust. Is there any more complete documentation? The book is incomplete. The book is undoubtedly incomplete, as most documents are, however I have found the Subversion Book to be among the best open-source documentation efforts of any project I've worked with. The book is maintained by a separate group, and if you have specific feedback for them, see the Feedback/Contributing heading on their web site: http://svnbook.org/
Re: Strange behavior
Remember to Reply All so that your message goes to the mailing list too, not just to me. On Aug 9, 2013, at 14:59, John Maher wrote: Thanks for your reply. I appreciate informing me that subversion is robust. I was concerned it was getting corrupted by the strange behavior. Plus you've also helped by telling me that the ignore property does not mean ignore, it means sometimes ignore. On page 68 of the book it explains that the ignore property is used to eliminate files from svn status. But your explanation matches my observations, thank you. The book is wrong again. I tried to delete the files from the repository with svn delete, but that failed because they were not part of the current revision. So it seems that I have to delete the repository and create it again (for the 3rd time). Does import work with the ignore property? It mentions it in the help, but I do not know if the help is wrong. If properties need to be applied to a working directory how do I use them with the import command BEFORE a working copy exists?. I followed the instructions in the book, created a repository and it came out all wrong, again. Can someone tell me how to get code files into the repository and stop the compiler generated files and directories? Thanks JM Page 68 of the PDF version of the book is within the section Ignoring Unversioned Items, but the items you're talking about are versioned, not unversioned. svn import will obey your svn autoprops: http://svnbook.red-bean.com/en/1.7/svn.advanced.props.html#svn.advanced.props.auto But I often prefer to avoid the svn import command and do an in-place import instead: http://subversion.apache.org/faq.html#in-place-import This affords you the opportunity to be more selective about what you import and to add properties before committing.
Re: Strange behavior
Guten Tag Ryan Schmidt, am Freitag, 9. August 2013 um 22:16 schrieben Sie: I tried to delete the files from the repository with svn delete, but that failed because they were not part of the current revision. So it seems that I have to delete the repository and create it again (for the 3rd time). No you don't, just update your working copy to HEAD and delete the files. This of course will work if your are on HEAD and the files are still there and not already deleted before. There's even no problem with deleting files in different directories within your working copy in the same commit. Besides that, you should really stop complaining about wrong documentation just because you are frustrated with getting things done, if it seems that you simply misunderstood important parts if it. 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: Strange behavior on directory delete/commit
You could also delete the directory directly in the repository using svn delete url -m message. This way you would avoid the problem of committing partial changes of your working copy. .. which is just another workaround.
RE: Strange behavior on directory delete/commit
I think SVN is behaving correctly. When you do svn commit foo you're telling Subversion to commit changes made in foo. There are no changes in foo because it's been deleted. The changes, instead, are in its parent directory, the one from where you issued your commands. That's why svn commi works, it assumes . as the path. I disagree. Providing a PATH argument should tell svn that one wants to commit the changes to foo. In this case it would be that foo was deleted. Since I want only the changes to foo to be versioned, it would not make sense to include all other changes within the parent directory. I think svn commit foo would work fine, provided you do not rmdir foo first; that was your error. I also have a feeling Subversion 1.7's new working copy arrangement will fix or at least change this behavior. So there's still a light at the far end of the tunnel! :o) From what I've read just now 1.7.X's WC arrangement will become alike hg's way. I understand well that the current svn infrastructure is not suited for this usecase. Would patching svn 1.6.X to fix the behaviour be feasible?
Re: Strange behavior on directory delete/commit
On Aug 3, 2011, at 03:04, Dominik Psenner wrote: I think svn commit foo would work fine, provided you do not rmdir foo first; that was your error. I also have a feeling Subversion 1.7's new working copy arrangement will fix or at least change this behavior. So there's still a light at the far end of the tunnel! :o) From what I've read just now 1.7.X's WC arrangement will become alike hg's way. I understand well that the current svn infrastructure is not suited for this usecase. Would patching svn 1.6.X to fix the behaviour be feasible? I doubt it. Or rather, the behavior is not broken. The user is broken. As I said: svn commit foo should have worked fine if you had not run rmdir foo beforehand. Don't run rmdir foo. Just run svn rm foo followed by svn commit foo and everything should work.
RE: Strange behavior on directory delete/commit
I doubt it. Or rather, the behavior is not broken. The user is broken. As I said: svn commit foo should have worked fine if you had not run rmdir foo beforehand. Don't run rmdir foo. Just run svn rm foo followed by svn commit foo and everything should work. True - it's nothing totally new to me. I just doubt the lusers who are going to use the frontend I'm writing for them understand the difference. :-)
Re: Strange behavior on directory delete/commit
On Aug 3, 2011, at 03:17, Dominik Psenner wrote: I doubt it. Or rather, the behavior is not broken. The user is broken. As I said: svn commit foo should have worked fine if you had not run rmdir foo beforehand. Don't run rmdir foo. Just run svn rm foo followed by svn commit foo and everything should work. True - it's nothing totally new to me. I just doubt the lusers who are going to use the frontend I'm writing for them understand the difference. :-) Then you must explain it to them. :) To move or delete items in a working copy, you must use svn commands. You must not use OS commands. That's just how it is.
RE: Strange behavior on directory delete/commit
Then you must explain it to them. :) To move or delete items in a working copy, you must use svn commands. You must not use OS commands. That's just how it is. This is going to be a long journey. *jokingly* Thanks for the insights and incredibly fast answers! It's awesome that you're working on the .svn meta-data folders problem. If you manage to get it settled, I believe 1.7.X is going to be great!
Re: Strange behavior on directory delete/commit
On Wed, Aug 03, 2011 at 10:25:07AM +0200, Dominik Psenner wrote: Then you must explain it to them. :) To move or delete items in a working copy, you must use svn commands. You must not use OS commands. That's just how it is. This is going to be a long journey. *jokingly* Thanks for the insights and incredibly fast answers! It's awesome that you're working on the .svn meta-data folders problem. If you manage to get it settled, I believe 1.7.X is going to be great! I'm not sure you understand the kinds problems the new working copy format is settling. You must still use svn commands instead of OS commands in 1.7. That won't change. I don't think it will ever change. The reason is that Subversion tracks operations explicitly, rather than implicitly. In other words, Subversion needs to modify meta-data in the .svn directory if you change something. If you run an OS-level command the actual disk state and the meta-data get out of sync. Subversion is not like git which goes Woaaahh... I just woke up and now... what??? What did the user DO??? Well, whatever, I'm just gonna take a wild guess to deal with this and go back to bed... Both approaches have advantages and disadvantages.
RE: Strange behavior on directory delete/commit
I'm not sure you understand the kinds problems the new working copy format is settling. For me it settles the major problem of multiple .svn folders in a checkout. You must still use svn commands instead of OS commands in 1.7. That won't change. I don't think it will ever change. The reason is that Subversion tracks operations explicitly, rather than implicitly. In other words, Subversion needs to modify meta-data in the .svn directory if you change something. If you run an OS-level command the actual disk state and the meta-data get out of sync. *sarcastic* The user does not care what levers subversion needs to pull to show him what parts of a file were modified. */sarcastic* Subversion is not like git which goes Woaaahh... I just woke up and now... what??? What did the user DO??? Well, whatever, I'm just gonna take a wild guess to deal with this and go back to bed... Please correct me if I'm wrong: Subversion is still an observer and whatever a user does, he must tell Subversion what he did in cases where subversion can't understand it by itself (i.e. file/folder rename/move that preserve history across the revisions). Every VCS I know works like this. Maybe one invents a VCS filesystem that can hook into the filesystem operations, but that's something that will be written on other papers. ;-) Back to topic: The current working copy layout is unable to handle the usecase I described since it needs the missing meta-data that was stored within the deleted folder itself. Thus Subversion 1.7 would need a special logic to handle these cases. One could discuss whether this should be fixed so that 1.7 behaves on folder deletes just alike file deletes. I leave that decision up to the devs since I'm unable to estimate the costs. The new working copy layout does not have the meta-data within subfolders and thus is able to commit just that change. HOORAY! This issue *can* be solved with WC-NG without special logics! --quote Ryan Schmidt-- I also have a feeling Subversion 1.7's new working copy arrangement will fix or at least change this behavior. --eof quote Ryan Schmidt-- Greetings, D.
RE: Strange behavior on directory delete/commit
[snip] Subversion is still an observer and whatever a user does, he must tell Subversion what he did in cases where subversion can't understand it by itself (i.e. file/folder rename/move that preserve history across the revisions). Every VCS I know works like this. Maybe one invents a VCS Sort of. Mercurial is perfectly happy if you tell it afterwards (before a commit of course) that you renamed that file and deleted the other one. This behavior comes in handy, if you have to rename some files in the IDE, because only the IDE knows what (and in which file) has to be renamed... Best regards Andreas -- Andreas Tscharner andreas.tschar...@metromec.ch -- Intruder on level one. All Aliens please proceed to level one. -- Call in Alien: Resurrection CT-Dienstleistungen neu bei Wenzel Metromec === Haben Sie einen Prototyp ohne Zeichnung oder Konstruktionsmodell? Suchen Sie in Ihren Bauteilen Materialschäden, Risse und Poren? Dann sind unsere neuen Dienstleistungen im Bereich der Computertomographie die perfekte Lösung für Ihre Anforderungen! Testen Sie uns und unsere neue WENZEL exaCT Anlage. Zögern Sie nicht und nehmen Sie noch heute mit uns Kontakt auf. mailto:c...@metromec.ch?subject=CT-Dienstleistungen
RE: Strange behavior on directory delete/commit
[snip] Subversion is still an observer and whatever a user does, he must tell Subversion what he did in cases where subversion can't understand it by itself (i.e. file/folder rename/move that preserve history across the revisions). Every VCS I know works like this. Maybe one invents a VCS Sort of. Mercurial is perfectly happy if you tell it afterwards (before a commit of course) that you renamed that file and deleted the other one. This behavior comes in handy, if you have to rename some files in the IDE, because only the IDE knows what (and in which file) has to be renamed... It smells differently, but is basically the same. :-) But now I understand what Stefan Sperling wanted to point out.
Re: Strange behavior on directory delete/commit
On Wed, Aug 03, 2011 at 11:27:48AM +0200, Dominik Psenner wrote: You must still use svn commands instead of OS commands in 1.7. That won't change. I don't think it will ever change. The reason is that Subversion tracks operations explicitly, rather than implicitly. In other words, Subversion needs to modify meta-data in the .svn directory if you change something. If you run an OS-level command the actual disk state and the meta-data get out of sync. *sarcastic* The user does not care what levers subversion needs to pull to show him what parts of a file were modified. */sarcastic* File modifications are detected automatically. This is easy because files have timestamps, and because Subversion has a pristine copy of each file in the .svn directory. And there is no ambiguity -- a file is either modified or it isn't. But for tree changes, Subversion provides commands, and users must use the commands to operate on the tree. The current working copy layout is unable to handle the usecase I described since it needs the missing meta-data that was stored within the deleted folder itself. Yes, this is one use case that 1.7 fixes. You can now replace directories without having to commit the deletion of the replaced directory separately from the addition of the replacing directory. E.g. you can delete a directory and move a different one on top: $ svn rm epsilon D epsilon D epsilon/zeta $ svn mv gamma epsilon A epsilon D gamma D gamma/delta $ svn status D gamma D gamma/delta R +epsilon D epsilon/zeta and commit the result in a single revision: r3 | stsp | 2011-08-03 12:27:38 +0200 (Wed, 03 Aug 2011) | 1 line Changed paths: R /trunk/epsilon (from /trunk/gamma:2) D /trunk/gamma 1.6 used to error out in the second step: svn: Cannot copy to 'epsilon' as it is scheduled for deletion
Re: Strange behavior on directory delete/commit
On 02/08/11 07:40, Dominik Psenner wrote: Hi, having a fresh subversion repository doing this as preparation: $ mkdir foo/ $ svn add foo $ svn commit -m test Adding foo Revision X sent. $ rmdir foo $ svn st ! foo $ svn delete foo D foo And finally this command fails: $ svn commit foo -m fail svn: entry foo has no URL This instead does work: $ svn commit -m works Delete foo Revision X sent. svn commit behaves inconsistently depending on whether a PATH argument is given or not. If it is a bug, it should get at least priority P2 because one is unable to commit partial changes to the WC as in this scenario: $ mkdir foo/ $ svn add foo A foo $ svn commit -m test Adding foo Revision X sent. $ rmdir foo $ svn st ! foo $ svn delete foo D foo $ touch bar $ touch foobar $ svn add bar foobar A bar A foobar $ svn commit foo bar svn: entry foo has no URL To get things done, one would have to backup foobar somewhere, revert foobar, do the commit without PATH arguments and copy foobar over to the WC. *eek* Let me know what you think about this! Greetings, D. I think SVN is behaving correctly. When you do svn commit foo you're telling Subversion to commit changes made in foo. There are no changes in foo because it's been deleted. The changes, instead, are in its parent directory, the one from where you issued your commands. That's why svn commi works, it assumes . as the path.
Re: Strange behavior on directory delete/commit
On Aug 2, 2011, at 07:11, Giulio Troccoli wrote: On 02/08/11 07:40, Dominik Psenner wrote: having a fresh subversion repository doing this as preparation: $ mkdir foo/ $ svn add foo $ svn commit -m test Adding foo Revision X sent. $ rmdir foo $ svn st !foo $ svn delete foo Dfoo And finally this command fails: $ svn commit foo -m fail svn: entry foo has no URL I think SVN is behaving correctly. When you do svn commit foo you're telling Subversion to commit changes made in foo. There are no changes in foo because it's been deleted. The changes, instead, are in its parent directory, the one from where you issued your commands. That's why svn commi works, it assumes . as the path. I think svn commit foo would work fine, provided you do not rmdir foo first; that was your error. I also have a feeling Subversion 1.7's new working copy arrangement will fix or at least change this behavior.
