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'
