On Mon, 2010-01-25 at 16:43 -0500, Adam wrote: > I must be making progress, because now I'm on the development team, sort > of, for a major project, as I'm assisting the developer of one small > area of libgphoto2, if you call that a major project. I figured I'm > likely to do something that will trash my development system, so I used > VirtualBox to create a VM just for this project. This way, no matter > how badly I wreck the "development" system, my "production" system (I > only have the one box) will remain usable. > > Anyway, I'm on a development team for this project which uses SVN. I > think I need to keep three separate versions on my "development" system: > (a) the latest SVN version, (b) the latest SVN version plus whatever the > developer sends me (as I think I'm the only other person involved, he > just emails me, instead of using "svn commit" for every minor change), > and (c) the latest SVN version plus whatever the developer sends me plus > whatever changes I'm trying out. > > So... can anybody suggest how can I keep track of all three versions on > my one "development" system without going crazy? Has anybody else found > a method that works for them? Or a better way to organize the whole > thing? Thanks for any help, suggestions, or clarification on this!
The latest SVN version is always at the server, so you don't have to have a separate working copy on your development system for that. Just 'svn up' to update. I recommend just having one local working copy in your case. Read about svn changelists here, http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.changelists That is how you can separate changes that came by patch from your own changes and manage them that way within the same working copy. If you find that incoming patches and your own changes are constantly touching the same files, then changelists won't work. You can always revert-apply a patch to remove those changes and be left only with your own. Create a patch of your changes (svn diff), svn revert, apply the incoming patch again, etc... and that way switch between your changes and the patches you got. But, if you find that incoming patches and your own changes are constantly modifying the same lines and you are getting conflicts, patches are not applying correctly, etc., then you need to get more complicated (depending on the observer). You can have two local working copies of the repo, one for incoming patches and one for your own. The other option is to have your own branch in the SVN repository for your changes. Then you can switch (svn switch) between that and trunk, for testing out incoming patches, within the same local working copy. You'll have to keep your branch up-to-date by merging it with trunk every once in a while (svn merge). This is a very good reference on SVN: http://svnbook.red-bean.com/ Saludos, -Renier _______________________________________________ Mid-Hudson Valley Linux Users Group http://mhvlug.org http://mhvlug.org/cgi-bin/mailman/listinfo/mhvlug Upcoming Meetings (6pm - 8pm) MHVLS Auditorium Feb 3 - Arduino Mar 3 - Sahana and 7 Years of MHVLUG Celebration Apr 7 - Nagios
