From: Peter M. <scr...@mo...> - 2010-06-23 04:48:01
|
On 23/06/2010 9:43, Thomas Morris wrote: > Hi, > > I am probably a few days behind everyone else, but just in case it > helps here are the commands I used to set up a shared repository (with > trees, to keep things simple until I know what I'm doing). > > bzr init-repo --trees stellarium > cd stellarium/ > > Create a local dev branch (including all history*, takes a few minutes > to pull the repo from launchpad) > bzr branch lp:stellarium stellarium.dev > > *I think this may only include the development branch history? > > Create branch for a new feature (rename as appropriate) > bzr branch stellarium.dev stellarium.ngccat > > Then the workflow in > http://wiki.bazaar.canonical.com/SharedRepositoryTutorial (Shared Repo > example) can be used. Since I don't have commit rights I'll send a > patch at the tip of the dev branch instead of doing bzr push. In > general is a branch or checkout recommended for new devs? As I > understand it a checkout forces the feature to be committed on the tip > of the dev branch, which is probably the most common situation. > > Thanks, > Thomas > If you want a local mirror of lp:stellarium, a checkout is probably what you want: bzr checkout lp:stellarium <LOCAL_NAME_HERE> Here's a complete sample workflow: // create a shared repo (under home folder in this example) bzr init-repo ~/stellarium cd ~/stellarium // make a local mirror of trunk from Launchpad // (you need write access on Launchpad to make commits, but that's not needed) bzr checkout lp:stellarium trunk // keep the local mirror current // (need to do this before doing most things with trunk) cd ~/stellarium/trunk bzr update // ---------- // create a feature/bug fix/hacking branch (in the same shared repo!) cd ~/stellarium bzr branch trunk myfix cd myfix // hack away // commit as you go bzr commit -m "fixed all the problems in the world - part 1/inf" bzr commit -m "fixed all the problems in the world - part 2/inf" // check if we're missing any revisions in trunk (optional) // (need to update local trunk mirror, as above) bzr missing // merge in trunk if needed // (again, be sure local trunk mirror is up-to-date) bzr merge ..\trunk // (note: could have just used 'bzr merge' as bzr remembers the path) // fix all the conflicts... // commit merge bzr commit -m "merged trunk" // get a diff/patch of your changes relative to trunk // (don't forget to update local trunk...) // (is there a better way to do this if you don't know the rev num?) bzr diff --old=..\trunk > DIFF_FILE_NAME // ---------- // If you have write access to Launchpad... // do the usual "make sure the code works" routine // merge changes into trunk cd ~/stellarium/trunk bzr merge ../f1 // commit merge // (if no conflicts, changes will be pushed to LP and then your local mirror) bzr commit -m "merged myfix" // (doing it this way will commit all your work under one trunk commit, but all the history is there and can be accessed) // (this keeps things neat and tidy in trunk without losing any info) // ('bzr log' on trunk will only show the merge commit - use 'bzr log -v' to see commits from the 'myfix' branch) // (or use 'bzr qlog' to get a pretty picture of the branching and merges) // ------------------------------ This workflow is fairly simple (and very fast for most operations) with the main problem being keeping your local trunk updated. You could leave out creating it and then create your branches off LP directly, which solves that problem and works fine for most operations: bzr branch lp:stellarium myfix (Does anyone know of a better solution for a local mirror? You could, for example, subscribe to LP notifications of commits and only update then. But there must be a better way?) There are of course unlimited other possible workflows; I use 'co-located' branches (bzr help colo-tutorial), which works better when using an IDE and everyone else will have their preferences. But perhaps a sample workflow like this, or whatever else is preferred, can be added to a 'Suggested Workflow' page on the Stellarium wiki? That would save everyone wasting hours figuring it all out and give some consistency to how people operate, hopefully making it easier for the core devs. Peter |