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. I also appreciate your description of the in-place import. I like the idea of being able to un-add a file. That allows you to experiment with wildcards without fear of damaging the repository. Adding a file to the repository that you do not wish can be considered damaging if it guarantees a merge conflict every time.
Thanks again JM -----Original Message----- From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] Sent: Monday, August 12, 2013 5:25 PM To: John Maher Cc: Subversion Users Subject: 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 operations in, you have to check it out from the repository, and then usually delete your original directory. But if there are any files in the original directory that you did not import, but that you still want to have in the new working copy, you have to manually move them over. If what got imported wasn't what you wanted, you have to clean it up later in the working copy -- "svn rm" files you didn't mean to import; "svn add" files you wanted to import but forgot; "svn mv" files around -- or "svn rm" the entire imported directory and try again, or maybe even delete the whole repository and start over if that's what you want (and it might be, if you imported huge files that you didn't need, since "svn rm" won't recover the space they used, or confidential files, since otherwise they'll forever be in the history). In my opinion, "svn import" is ok for importing small collections of files, where you want to import everything (or are sure your global-ignores cover every file you don't want to import) and don't care about properties (or are sure your auto-props cover every situation). For larger or more complicated imports, I choose the in-place import method. == In-Place Import == Instead of "svn import", I often prefer and in-place import. In this method, you first "svn mkdir" an empty directory in the repository where your files will go. Then you "svn co" this directory on top of your directory of original files, thereby transforming it into a working copy with unversioned files. You can then "svn add" files you want to import. If you add a file you didn't want (perhaps by running "svn add *") you can "svn revert" the file to essentially "un-add" it. You can "svn ps" to set additional properties. (Perhaps you want to set "svn:ignore" on some directories.) You haven't committed anything yet, except for the creation of the empty directory. You can continue to modify your pending commit as desired, using "svn st" as often as you like to inspect what will be committed, and finally "svn ci" when ready to commit it. And as noted, your original directory of files has *become* the working copy, which is often what people want anyway. The FAQ entry on in-place import is pretty limited, I concede. I assume that since it is a FAQ entry it is not in the book. I would like to see the in-place import method described in greater detail, in the book, replacing the FAQ entry.
