Re: [Stellarium-pubdevel] O.k., now what?

[Thomas M. <tom...@go...>]

Hi Peter,

Thanks very much for your help. I'm confident that bazaar is going to
make everything simpler once I get the hang of it.  As an aside, is
there a reason for the discrepancy between bzr head at rev 4907 (as of
10hrs ago), whereas the SVN rev was over 5000 when I last checked?
Perhaps there isn't a 1-1 correspondence as I expected!

Thanks,
Thomas

On 23 June 2010 05:47, Peter Mousley <scr...@mo...> wrote:
> 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
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Stellarium-pubdevel mailing list
> Ste...@li...
> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
>