On Mon, Jan 25, 2010 at 6:43 PM, Renier Morales <[email protected]> wrote:
> 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 > > If you're familiar with (or want to learn) git, and you're both generally working on the same branch all the time, you could check out git svn. http://tinyurl.com/ycjgd7t /thor
_______________________________________________ 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
