From: Timothy R. <tr...@si...> - 2010-06-16 21:24:11
|
The switch was made to Bazaar. After using it some, I'm concerned it didn't bring any benefits, only omplexity, but, I'll wait and see. The big question is: now what? What is the workflow supposed to be? 1) Are we to create branches from the command line, or from the laucnhpad site? I created one from the command line, but there seems to be no way to link it to the stellarium site. 2) is each change to be in it's own branch? If not, there was no reason to switch from subversion, as we had branches there too. If so, what is the work flow for approving that branch, and merging to trunk? In general what is the intention of how we are to use any SCM for getting code into the app? I have two or three changes to the core, related only in that one or more plugin needed that support. I'm confused as to how bazaar is to help make progress in getting these changes reviewed, and in to trunk. |
From: Timothy R. <tr...@si...> - 2010-06-17 00:11:44
|
On Jun 16, 2010, at 5:23 PM, Timothy Reaves wrote: > The switch was made to Bazaar. After using it some, I'm concerned it didn't bring any benefits, only omplexity, but, I'll wait and see. The big question is: now what? What is the workflow supposed to be? > > 1) Are we to create branches from the command line, or from the laucnhpad site? I created one from the command line, but there seems to be no way to link it to the stellarium site. > > 2) is each change to be in it's own branch? If not, there was no reason to switch from subversion, as we had branches there too. If so, what is the work flow for approving that branch, and merging to trunk? > > In general what is the intention of how we are to use any SCM for getting code into the app? I have two or three changes to the core, related only in that one or more plugin needed that support. I'm confused as to how bazaar is to help make progress in getting these changes reviewed, and in to trunk. I've scoured about all of the documentation I can find on LaunchPad about how they think branches should be used. What I've come up with is: *) create a branch *) implement a single feature/bug fix *) push it to LaunchPad *) associate a bug or blueprint with the branch *) recommend the branch for merging. Is this everyone else's understanding? Am I missing anything? Assuming it's basically correct, a question remains with where is the best place to create the branches. It can also get tricky if I have a branch, that has several other branches merged into it. This means that for the active branch to make it to trunk branch (isn't that an oxymoron?), they have to be merged in order, with none missed. Comments? Corrections? Rejoinders? |
From: Timothy R. <tr...@si...> - 2010-06-17 03:21:55
|
On Jun 16, 2010, at 8:11 PM, Timothy Reaves wrote: > > On Jun 16, 2010, at 5:23 PM, Timothy Reaves wrote: > >> The switch was made to Bazaar. After using it some, I'm concerned it didn't bring any benefits, only omplexity, but, I'll wait and see. The big question is: now what? What is the workflow supposed to be? >> >> 1) Are we to create branches from the command line, or from the laucnhpad site? I created one from the command line, but there seems to be no way to link it to the stellarium site. >> >> 2) is each change to be in it's own branch? If not, there was no reason to switch from subversion, as we had branches there too. If so, what is the work flow for approving that branch, and merging to trunk? >> >> In general what is the intention of how we are to use any SCM for getting code into the app? I have two or three changes to the core, related only in that one or more plugin needed that support. I'm confused as to how bazaar is to help make progress in getting these changes reviewed, and in to trunk. > > > I've scoured about all of the documentation I can find on LaunchPad about how they think branches should be used. What I've come up with is: > > *) create a branch > *) implement a single feature/bug fix > *) push it to LaunchPad > *) associate a bug or blueprint with the branch > *) recommend the branch for merging. > > Is this everyone else's understanding? Am I missing anything? Assuming it's basically correct, a question remains with where is the best place to create the branches. It can also get tricky if I have a branch, that has several other branches merged into it. This means that for the active branch to make it to trunk branch (isn't that an oxymoron?), they have to be merged in order, with none missed. > > Comments? Corrections? Rejoinders? I've attempted a first go at how this workflow could work. I've created a blueprint here https://blueprints.launchpad.net/stellarium/+spec/stelobject-refactor-callback-to-signal , and I've associated with a brach that implements the refactoring. The branch was pushed to my own area in LaunchPad, trying to follow http://wiki.bazaar.canonical.com/SharedRepositoryLayouts#simple-developer-naming-project-joe-foo-project-barry-bar . On my local machine I have a shared repository created, and this makes each brach as small as it would be in SVN (about one tenth the size of a non-shared repository branch). When I pushed however, the full data was uploaded to ~treaves/stellarium/treaves1 . What I'll want to see if this makes ~treaves/stellarium a shared repository. If not, pushing braches is going to be an awful lot of data! I have proposed this branch for merging; see https://code.launchpad.net/~treaves/stellarium/treaves1/+merge/27791 . In general, I was thinking the work flow would be to re-use this branch after the merge is approved, or rolled back. This would be to limit the amount of data pushed. |
From: Peter M. <scr...@mo...> - 2010-06-17 05:44:33
|
On 17/06/2010 13:21, Timothy Reaves wrote: > On Jun 16, 2010, at 8:11 PM, Timothy Reaves wrote: > > >> On Jun 16, 2010, at 5:23 PM, Timothy Reaves wrote: >> >> >>> The switch was made to Bazaar. After using it some, I'm concerned it didn't bring any benefits, only omplexity, but, I'll wait and see. The big question is: now what? What is the workflow supposed to be? >>> >>> 1) Are we to create branches from the command line, or from the laucnhpad site? I created one from the command line, but there seems to be no way to link it to the stellarium site. >>> >>> 2) is each change to be in it's own branch? If not, there was no reason to switch from subversion, as we had branches there too. If so, what is the work flow for approving that branch, and merging to trunk? >>> >>> In general what is the intention of how we are to use any SCM for getting code into the app? I have two or three changes to the core, related only in that one or more plugin needed that support. I'm confused as to how bazaar is to help make progress in getting these changes reviewed, and in to trunk. >>> >> >> I've scoured about all of the documentation I can find on LaunchPad about how they think branches should be used. What I've come up with is: >> >> *) create a branch >> *) implement a single feature/bug fix >> *) push it to LaunchPad >> *) associate a bug or blueprint with the branch >> *) recommend the branch for merging. >> >> Is this everyone else's understanding? Am I missing anything? Assuming it's basically correct, a question remains with where is the best place to create the branches. It can also get tricky if I have a branch, that has several other branches merged into it. This means that for the active branch to make it to trunk branch (isn't that an oxymoron?), they have to be merged in order, with none missed. >> >> Comments? Corrections? Rejoinders? >> > I've attempted a first go at how this workflow could work. I've created a blueprint here https://blueprints.launchpad.net/stellarium/+spec/stelobject-refactor-callback-to-signal , and I've associated with a brach that implements the refactoring. > > The branch was pushed to my own area in LaunchPad, trying to follow http://wiki.bazaar.canonical.com/SharedRepositoryLayouts#simple-developer-naming-project-joe-foo-project-barry-bar . On my local machine I have a shared repository created, and this makes each brach as small as it would be in SVN (about one tenth the size of a non-shared repository branch). When I pushed however, the full data was uploaded to ~treaves/stellarium/treaves1 . What I'll want to see if this makes ~treaves/stellarium a shared repository. If not, pushing braches is going to be an awful lot of data! > > I have proposed this branch for merging; see https://code.launchpad.net/~treaves/stellarium/treaves1/+merge/27791 . In general, I was thinking the work flow would be to re-use this branch after the merge is approved, or rolled back. This would be to limit the amount of data pushed. > > > ------------------------------------------------------------------------------ > 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 > Do you have any hair left? It sounds like you've probably pulled it all out by now... A distributed VCS is certainly very different to a centralised system and there's a pretty steep learning curve. It will be worth it in the long run, but I understand your frustration. It actually doesn't much matter where branches are stored - they should all get sync'd as and when required. If you don't wish to share your work, you may as well keep everything local, i.e. use local branches. Even if you do want to share, you can still keep everything local and then just send/post patches. If you want to work collaboratively on a branch then it is best to keep a copy on Launchpad so all relevant devs can sync with that. Here's some (incomplete) notes: - you definitely want to use shared repos (otherwise the 350+ MB repo will be copied with every branch...) - you may also want to use 'colocated' (sic) branches (similar to git and hg - only have one set of working files at a time) - do use a branch for each bug fix, new feature, etc. (this is perhaps the biggest benefit of a DVCS) I don't think there is a 'best' workflow, but you will develop one over time. But something like this should work: - maintain the 'master' branch/trunk on Launchpad - each dev keeps a mirror of the master - create a local branch for each bug/feature/etc., you're working on - regularly merge the master into your working branches - merge your branch into the local master when you're done (and make sure everything is okay!) - push to the Launchpad master - delete your local branch (obviously only if it's not required anymore) To collaborate, you can either branch the master in the Launchpad repo (which means everyone will get the changes) or you can create a branch in a different repo (your Launchpad user area for example). For the later, create the branch directly in Launchpad (I think there's a button 'Create a branch'). That way, the branch is done locally on Launchpad and you won't have to upload the entire repo! You can then just create a local branch (from your local master mirror) and point it at your Launchpad branch for syncing. When the work's complete, just merge it into master/trunk. For devs without commit access, the workflow is pretty similar: - get a copy of the master repo - create a branch and hack away - send a patch or make the branch publicly available - reviewer creates a new local branch and applies the patch or pulls the public branch - when everything is okay, the reviewer merges it into master/trunk (guidelines for the preferred method of submitting patches, etc., should be put on the project wiki) (it would also be good to include a sample workflow for people not familiar with bzr - how to install, how to branch, how to diff, ...) And that's where a big advantage lies - all devs, even those without commit access, can easily manage their own local branches and operate much more independently. Or, if required, you can collaborate much more easily with someone working on the same section of code, without everyone else being effected by what you're doing. The policy for the Launchpad master is something to be determined. You can have it maintain only a master branch (mainline trunk) or it can hold multiple branches. It can be kept such that the 'master' branch is always in good working order with one or more other branches for staging commits. But it's best not to be like svn, where almost everything is committed to trunk because branching is so painful. Finally, you made several comments/asked several questions about merging. Basically, if two branches have, at some point, a common parent, you should only ever have to merge changes since that separation point, i.e. you should not have to upload the entire repo. Likewise, if it is required to make a new branch either locally or remotely, you should only have to send the changes from the last common point in the two repos. (This is where git's rebase seems so good to me - you rebase your changes against the latest upstream and then only have very minor changes to worry about. Bazaar has rebase/rewrite support but its use seems to be discouraged - I just don't understand why.) May your hair grow long and thick! Peter |
From: Fabien C. <fab...@go...> - 2010-06-17 09:12:06
|
On Thu, Jun 17, 2010 at 07:44, Peter Mousley <scr...@mo...> wrote: > On 17/06/2010 13:21, Timothy Reaves wrote: >> On Jun 16, 2010, at 8:11 PM, Timothy Reaves wrote: >> >> >>> On Jun 16, 2010, at 5:23 PM, Timothy Reaves wrote: >>> >>> >>>> The switch was made to Bazaar. After using it some, I'm concerned it didn't bring any benefits, only omplexity, but, I'll wait and see. The big question is: now what? What is the workflow supposed to be? >>>> >>>> 1) Are we to create branches from the command line, or from the laucnhpad site? I created one from the command line, but there seems to be no way to link it to the stellarium site. >>>> >>>> 2) is each change to be in it's own branch? If not, there was no reason to switch from subversion, as we had branches there too. If so, what is the work flow for approving that branch, and merging to trunk? >>>> >>>> In general what is the intention of how we are to use any SCM for getting code into the app? I have two or three changes to the core, related only in that one or more plugin needed that support. I'm confused as to how bazaar is to help make progress in getting these changes reviewed, and in to trunk. >>>> >>> >>> I've scoured about all of the documentation I can find on LaunchPad about how they think branches should be used. What I've come up with is: >>> >>> *) create a branch >>> *) implement a single feature/bug fix >>> *) push it to LaunchPad >>> *) associate a bug or blueprint with the branch >>> *) recommend the branch for merging. >>> >>> Is this everyone else's understanding? Am I missing anything? Assuming it's basically correct, a question remains with where is the best place to create the branches. It can also get tricky if I have a branch, that has several other branches merged into it. This means that for the active branch to make it to trunk branch (isn't that an oxymoron?), they have to be merged in order, with none missed. >>> >>> Comments? Corrections? Rejoinders? >>> >> I've attempted a first go at how this workflow could work. I've created a blueprint here https://blueprints.launchpad.net/stellarium/+spec/stelobject-refactor-callback-to-signal , and I've associated with a brach that implements the refactoring. >> >> The branch was pushed to my own area in LaunchPad, trying to follow http://wiki.bazaar.canonical.com/SharedRepositoryLayouts#simple-developer-naming-project-joe-foo-project-barry-bar . On my local machine I have a shared repository created, and this makes each brach as small as it would be in SVN (about one tenth the size of a non-shared repository branch). When I pushed however, the full data was uploaded to ~treaves/stellarium/treaves1 . What I'll want to see if this makes ~treaves/stellarium a shared repository. If not, pushing braches is going to be an awful lot of data! >> >> I have proposed this branch for merging; see https://code.launchpad.net/~treaves/stellarium/treaves1/+merge/27791 . In general, I was thinking the work flow would be to re-use this branch after the merge is approved, or rolled back. This would be to limit the amount of data pushed. >> >> >> ------------------------------------------------------------------------------ >> 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 >> > > Do you have any hair left? It sounds like you've probably pulled it all > out by now... > > A distributed VCS is certainly very different to a centralised system > and there's a pretty steep learning curve. It will be worth it in the > long run, but I understand your frustration. > > It actually doesn't much matter where branches are stored - they should > all get sync'd as and when required. If you don't wish to share your > work, you may as well keep everything local, i.e. use local branches. > Even if you do want to share, you can still keep everything local and > then just send/post patches. If you want to work collaboratively on a > branch then it is best to keep a copy on Launchpad so all relevant devs > can sync with that. Here's some (incomplete) notes: > > - you definitely want to use shared repos > (otherwise the 350+ MB repo will be copied with every branch...) > - you may also want to use 'colocated' (sic) branches > (similar to git and hg - only have one set of working files at a time) > - do use a branch for each bug fix, new feature, etc. > (this is perhaps the biggest benefit of a DVCS) > > I don't think there is a 'best' workflow, but you will develop one over > time. But something like this should work: > - maintain the 'master' branch/trunk on Launchpad > - each dev keeps a mirror of the master > - create a local branch for each bug/feature/etc., you're working on > - regularly merge the master into your working branches > - merge your branch into the local master when you're done > (and make sure everything is okay!) > - push to the Launchpad master > - delete your local branch (obviously only if it's not required anymore) > > To collaborate, you can either branch the master in the Launchpad repo > (which means everyone will get the changes) or you can create a branch > in a different repo (your Launchpad user area for example). For the > later, create the branch directly in Launchpad (I think there's a button > 'Create a branch'). That way, the branch is done locally on Launchpad > and you won't have to upload the entire repo! You can then just create > a local branch (from your local master mirror) and point it at your > Launchpad branch for syncing. When the work's complete, just merge it > into master/trunk. > > For devs without commit access, the workflow is pretty similar: > - get a copy of the master repo > - create a branch and hack away > - send a patch or make the branch publicly available > - reviewer creates a new local branch and applies the patch or pulls the > public branch > - when everything is okay, the reviewer merges it into master/trunk > (guidelines for the preferred method of submitting patches, etc., should > be put on the project wiki) > (it would also be good to include a sample workflow for people not > familiar with bzr - how to install, how to branch, how to diff, ...) > > And that's where a big advantage lies - all devs, even those without > commit access, can easily manage their own local branches and operate > much more independently. Or, if required, you can collaborate much more > easily with someone working on the same section of code, without > everyone else being effected by what you're doing. > > The policy for the Launchpad master is something to be determined. You > can have it maintain only a master branch (mainline trunk) or it can > hold multiple branches. It can be kept such that the 'master' branch is > always in good working order with one or more other branches for staging > commits. But it's best not to be like svn, where almost everything is > committed to trunk because branching is so painful. > > Finally, you made several comments/asked several questions about > merging. Basically, if two branches have, at some point, a common > parent, you should only ever have to merge changes since that separation > point, i.e. you should not have to upload the entire repo. Likewise, if > it is required to make a new branch either locally or remotely, you > should only have to send the changes from the last common point in the > two repos. (This is where git's rebase seems so good to me - you rebase > your changes against the latest upstream and then only have very minor > changes to worry about. Bazaar has rebase/rewrite support but its use > seems to be discouraged - I just don't understand why.) > > May your hair grow long and thick! > > Peter Many thanks Peter, you seem to know more than all of us about distributed VCS! As you mention in you reply, we have to decide on our branch strategy. My personal feeling is that for the main developers (with commit rights) we should try to keep the development cycle close to the previous SVN-based one (based on the trunk main branch). This was quite successful in the previous years so I don't see any reason to change that. The project is not that huge, and the main committers know what they can or can't commit in the trunk (e.g. each plugin has someone responsible for it). I personally will use bzr just like I used svn before, with the extra flexibility to have branches for very experimental work. Now for external developers without commit rights, or for changes on the core which need to be reviewed like what Timothy is doing, bzr is also very clearly usefuland the work flow is also quite clear: create a separated branch and send a merge request if needed. Now one of the remaining problem which is not too clear to me is how to deal with series/releases. We could create one branch per series (e.g. 0.9.x, 0.10.x) with tags per release, or one branch per release, or no branch at all excepted trunk. I would prefer to keep the complexity as low as possible by minimizing the number of official/public branches, so creating all those branch makes sense only if it's really necessary. So far we almost never worked on maintaining another branch than the trunk. Any idea? Fabien |
From: Peter M. <scr...@mo...> - 2010-06-17 11:07:06
|
On 17/06/2010 19:11, Fabien Chéreau wrote: > Many thanks Peter, you seem to know more than all of us about > distributed VCS! As you mention in you reply, we have to decide on our > branch strategy. My personal feeling is that for the main developers > (with commit rights) we should try to keep the development cycle close > to the previous SVN-based one (based on the trunk main branch). This > was quite successful in the previous years so I don't see any reason > to change that. The project is not that huge, and the main committers > know what they can or can't commit in the trunk (e.g. each plugin has > someone responsible for it). > I personally will use bzr just like I used svn before, with the extra > flexibility to have branches for very experimental work. Now for > external developers without commit rights, or for changes on the core > which need to be reviewed like what Timothy is doing, bzr is also very > clearly usefuland the work flow is also quite clear: create a > separated branch and send a merge request if needed. > > Now one of the remaining problem which is not too clear to me is how > to deal with series/releases. We could create one branch per series > (e.g. 0.9.x, 0.10.x) with tags per release, or one branch per release, > or no branch at all excepted trunk. I would prefer to keep the > complexity as low as possible by minimizing the number of > official/public branches, so creating all those branch makes sense > only if it's really necessary. So far we almost never worked on > maintaining another branch than the trunk. Any idea? > > Fabien > I don't actually know all that much - there are others out there with much more experience using DVCS. However, I can offer an opinion... I think you've got it pretty much correct re workflow - it shouldn't be too different from svn but you'll have the advantages of local commits and branching. I would think most people would appreciate the main/master repo being kept clean and only having final code committed. It will just take some time to get used to managing branches. As for branching the master, someone else may be able to give some guidance; for a larger project where you maintain fixes, etc., on previous versions you would definitely branch. But if you're not backporting anything, I'm not sure there is much benefit (each clone of the repo contains the entire history regardless, and it is no more difficult to branch from an old commit as from the head). What I would consider more beneficial would be to separate each series into separate repos to reduce their size; 300+ MB isn't exactly convenient. I don't know if the repos could be linked in some way, but I wouldn't think it necessary - does anyone really need 0.08 code in the main repo? (and it is easy to merge between repos even if they do want to use something ancient). Perhaps there are other implications, but it's just a thought. (To clarify about branching... Typically in a DVCS, the repo contains the entire history, including all branches. If you branch at 0.10.5 for example, but then don't actually do anything with the 0.10.5 branch, the history looks just the same as if you had never branched - the first commit of the 0.10.6 series will be a child of the 0.10.5 commit and there won't be any siblings, so it looks just as if you hadn't branched. Later on, if you did want to backport a change to make 0.10.5.1 then you would just branch at that time, using 'bzr branch <trunk> <0.10.5.1> -r 0.10.5' (where the bits in <> are the appropriate names and assuming you'd tagged the 0.10.5 commit). Couldn't be easier! It also needs to be remembered that just because you delete the files from a branch doesn't mean it doesn't still exist - if it was committed to the repo then it can always be retrieved.) So, IMHO the only decision that really matters at this time is what to use as the 'base' repo - the complete, 300+ MB history that is there now or something smaller. Perhaps someone else has some thoughts on this? Peter |
From: Timothy R. <tr...@si...> - 2010-06-17 13:53:31
|
On Jun 17, 2010, at 5:11 AM, Fabien Chéreau wrote: > --snip-- > Now one of the remaining problem which is not too clear to me is how > to deal with series/releases. We could create one branch per series > (e.g. 0.9.x, 0.10.x) with tags per release, or one branch per release, > or no branch at all excepted trunk. I would prefer to keep the > complexity as low as possible by minimizing the number of > official/public branches, so creating all those branch makes sense > only if it's really necessary. So far we almost never worked on > maintaining another branch than the trunk. Any idea? > > http://wiki.bazaar.canonical.com/SharedRepositoryLayouts is of some use. The have several ways that branches can be handled. |
From: Barry G. <bar...@ho...> - 2010-06-19 23:03:58
|
Hi Fabien How do I get the source code now that the change has been made to bzr. I followed the instructions but aborted after the download got to 150 MB but still no sourcecode in the folder. I can't see any advantage over the old svn that worked well Barry Gerdes Beaumont Hills Observatory S 33' 41' 44" E 150' 56' 32" _________________________________________________________________ New, Used, Demo, Dealer or Private? Find it at CarPoint.com.au http://clk.atdmt.com/NMN/go/206222968/direct/01/ |
From: Peter M. <scr...@mo...> - 2010-06-20 02:16:40
|
On 20/06/2010 9:03, Barry Gerdes wrote: > Hi Fabien > > How do I get the source code now that the change has been made to bzr. > I followed the instructions but aborted after the download got to 150 > MB but still no sourcecode in the folder. I can't see any advantage > over the old svn that worked well > > Barry Gerdes > Beaumont Hills Observatory > S 33' 41' 44" E 150' 56' 32" > Barry, It's about 330 MB to download - you just needed to be patient :) This is why I raised the option of splitting the repo - if it's too big some people will be turned off downloading. Although, I do think bazaar should include a 'percentage complete' indicator like other VCS... but that's getting off topic. (I should mention - if you haven't deleted the already downloaded portion of the repo, you should be able to continue it by issuing the same command from the same folder.) Unless you've set a --no-trees option (unlikely), the working tree (code) should be generated after the repo is downloaded. You can get a svn-like experience by using 'lightweight checkouts'; a lightweight checkout only gives you the working tree (i.e. the actual code files, not the full repo). This should be about a 100 MB download. The source repo (Launchpad in this case) then becomes your working repo, so anything you do refers back to the repo Launchpad, i.e. just like svn always referred back to it's repo on SourceForge (that is, slow and painful!). You use 'bzr checkout --lightweight lp:stellarium' to do this, but beware there are some limitations to using a lightweight checkout as opposed to a 'heavyweight' checkout or branch (see bzr manual for details). And you still won't see files until the download is complete. Given your involvement in the Stellarium project, you'd be best to create a local copy of the repo (using a standard 'heavyweight' checkout, branch or perhaps even a 'tracking' branch, depending on what you want to do - again, check the bzr manual for details of different workflows, but a basically a checkout is more svn like than a branch). ----- Apologies if you already know the following, but hopefully it will be useful to someone else anyway... (and to the flamers - I know it is not an exact description of every VCS, but it's just to give a high-level explanation) In a version control system (VCS), the complete history of one or more files is stored. However, it is not every saved (committed) copy of each file that is stored but rather a series of 'file differences', i.e. changes made between versions (commits). All of this information is stored in a repository (repo). To retrieve a copy of the actual files from any given time, the VCS pulls all the required info from the repo - it 'constructs' the actual files from all of the fragments (file differences) stored in the repo. In the case of Bazaar, the repo is stored in a hidden '.bzr' folder (have a look in there and you'll see 'pack' files, which contain the file data, and config files, etc.). So when you 'branch' a repo using Bazaar (usually called 'clone' in other VCS), it will first download the repo (which contains all details from all commits) and then construct the actual working files from this repo data. Hence your not having any 'files' until the download is complete. The advantage of having a complete, local copy of the repo is that you can very quickly: change between versions of the files; compare versions of the files; create your own local branches of the files; make your own local commits; etc. All of this is much faster than when using a non-distributed VCS (such as subversion). It's just a pain to have to get the entire repo in the first place! (but see "lightweight checkouts" above for an alternative) ----- Given these questions are going to arise frequently, perhaps some info could be included in the Stellarium wiki? Peter |
From: Peter M. <scr...@mo...> - 2010-06-20 02:25:51
|
On 20/06/2010 12:16, Peter Mousley wrote: > On 20/06/2010 9:03, Barry Gerdes wrote: >> Hi Fabien >> >> How do I get the source code now that the change has been made to >> bzr. I followed the instructions but aborted after the download got >> to 150 MB but still no sourcecode in the folder. I can't see any >> advantage over the old svn that worked well >> >> Barry Gerdes >> Beaumont Hills Observatory >> S 33' 41' 44" E 150' 56' 32" >> > Barry, > > < snip - long winded discussion about VCS) > Peter Checkout (bad pun) http://wiki.bazaar.canonical.com/CheckoutTutorial for a short intro to checkouts and how they compare to branches. But regardless of what branches/checkouts you use, you will still almost certainly want to use a 'shared repo' (that is, a parent folder for all things Stellarium that contains the complete repo, which is then shared by any branches/checkouts you make - much faster downloads and less storage space once it's set up). Peter |
From: Barry G. <bar...@ho...> - 2010-06-20 03:03:15
|
Hi Peter Its OK now. I used another computer to do the big download I let it complete this time. and the last 40+ MB was the source code. The lap top I was using (in bed) was "running out of steam" and I could not wait for the battery to go flat. I built the code without any further bother using MSYS. I gave up Qt Creator some time ago. The change in build numbering is a bit confusing. I did not check to find the change point I also found an easy way to update using the TortoiseBZR Shell. Just a couple of clicks in the source folder. I am not interested in patching, changing or having my own branch. I just compile the source to see how the program is progressing. I did read through the tutorial but it did not mean a great deal to me without some practical testing. Barry Gerdes Beaumont Hills Observatory S 33' 41' 44" E 150' 56' 32" Date: Sun, 20 Jun 2010 12:25:43 +1000 From: scr...@mo... To: ste...@li... Subject: Re: [Stellarium-pubdevel] O.k., now what? On 20/06/2010 12:16, Peter Mousley wrote: On 20/06/2010 9:03, Barry Gerdes wrote: Hi Fabien How do I get the source code now that the change has been made to bzr. I followed the instructions but aborted after the download got to 150 MB but still no sourcecode in the folder. I can't see any advantage over the old svn that worked well Barry Gerdes Beaumont Hills Observatory S 33' 41' 44" E 150' 56' 32" Barry, < snip - long winded discussion about VCS) Peter Checkout (bad pun) http://wiki.bazaar.canonical.com/CheckoutTutorial for a short intro to checkouts and how they compare to branches. But regardless of what branches/checkouts you use, you will still almost certainly want to use a 'shared repo' (that is, a parent folder for all things Stellarium that contains the complete repo, which is then shared by any branches/checkouts you make - much faster downloads and less storage space once it's set up). Peter _________________________________________________________________ If It Exists, You'll Find it on SEEK. Australia's #1 job site http://clk.atdmt.com/NMN/go/157639755/direct/01/ |
From: Peter M. <scr...@mo...> - 2010-06-20 03:23:58
|
On 20/06/2010 13:03, Barry Gerdes wrote: > Hi Peter > > Its OK now. I used another computer to do the big download I let it > complete this time. and the last 40+ MB was the source code. The lap > top I was using (in bed) was "running out of steam" and I could not > wait for the battery to go flat. > > I built the code without any further bother using MSYS. I gave up Qt > Creator some time ago. The change in build numbering is a bit > confusing. I did not check to find the change point > > I also found an easy way to update using the TortoiseBZR Shell. Just a > couple of clicks in the source folder. > I am not interested in patching, changing or having my own branch. I > just compile the source to see how the program is progressing. > > I did read through the tutorial but it did not mean a great deal to me > without some practical testing. > > > Barry Gerdes > Beaumont Hills Observatory > S 33' 41' 44" E 150' 56' 32" > Not that it really matters, but it shouldn't "download the source code" per se; it should download the repo and then construct the working files (source code, etc.) from that. Even with a lightweight checkout (which is source only, no repo) I think this is pretty much how it works - it creates a kind of temporary local repo and then generates the code from there. But I stand to be corrected. I know you've compiled older versions for bug testing, etc., which is why I suggested you probably want a copy of the repo - makes switching between versions much faster. If that's all you want to do, then 'bzr checkout lp:stellarium' should be right for you. Then just 'bzr pull' to update. (If you're doing something different, I'd be interested to know what - still trying to get my head around the 'bzr way' of doing things, as opposed to git of hg.) And nothing beats actually doing it (except our rather sad download speeds and quotas...) |
From: Barry G. <bar...@ho...> - 2010-06-20 04:52:31
|
Hi Peter Windows XP Yes I think the source code is reconstructed from the repo\packs (159 MB) as you say. I was watching the download and it got to about 160MB and then the source code suddenly appeared as the download stopped. When I got the source I had a look for ways to update, I missed the bzr pull lp: but I tried a few other things but each time I got an error saying virtually "you can't do that". However when I installed bzr there was a box to tick for the Tortoise Shell (no pun intended) which I ticked. After fiddling with direct calls to bzr I looked in files-tortoise bazaar-update. This was real simple. I just entered the stellarium folder and clicked update / OK and it did a checkout just like the svn. As a matter of interest I also went though the same procedure in Windows 7 ultimate 64 bit on a dual core machine. No problem. The only difference being the compile time was about half. Next I will try Linux (in a virtual machine in Windows 7). The source code you see in stellarium when you click on browse bazaar is probably just generated from the repo as required but I haven't seen much direct access to this. Barry Gerdes Beaumont Hills Observatory S 33' 41' 44" E 150' 56' 32" Date: Sun, 20 Jun 2010 13:23:48 +1000 From: scr...@mo... To: ste...@li... Subject: Re: [Stellarium-pubdevel] O.k., now what? On 20/06/2010 13:03, Barry Gerdes wrote: Hi Peter Its OK now. I used another computer to do the big download I let it complete this time. and the last 40+ MB was the source code. The lap top I was using (in bed) was "running out of steam" and I could not wait for the battery to go flat. I built the code without any further bother using MSYS. I gave up Qt Creator some time ago. The change in build numbering is a bit confusing. I did not check to find the change point I also found an easy way to update using the TortoiseBZR Shell. Just a couple of clicks in the source folder. I am not interested in patching, changing or having my own branch. I just compile the source to see how the program is progressing. I did read through the tutorial but it did not mean a great deal to me without some practical testing. Barry Gerdes Beaumont Hills Observatory S 33' 41' 44" E 150' 56' 32" Not that it really matters, but it shouldn't "download the source code" per se; it should download the repo and then construct the working files (source code, etc.) from that. Even with a lightweight checkout (which is source only, no repo) I think this is pretty much how it works - it creates a kind of temporary local repo and then generates the code from there. But I stand to be corrected. I know you've compiled older versions for bug testing, etc., which is why I suggested you probably want a copy of the repo - makes switching between versions much faster. If that's all you want to do, then 'bzr checkout lp:stellarium' should be right for you. Then just 'bzr pull' to update. (If you're doing something different, I'd be interested to know what - still trying to get my head around the 'bzr way' of doing things, as opposed to git of hg.) And nothing beats actually doing it (except our rather sad download speeds and quotas...) _________________________________________________________________ Browse profiles for FREE! Meet local singles online. http://clk.atdmt.com/NMN/go/150855801/direct/01/ |
From: Peter M. <scr...@mo...> - 2010-06-20 08:21:53
|
On 20/06/2010 14:52, Barry Gerdes wrote: > Hi Peter > > Windows XP > > Yes I think the source code is reconstructed from the repo\packs (159 > MB) as you say. I was watching the download and it got to about 160MB > and then the source code suddenly appeared as the download stopped. > > When I got the source I had a look for ways to update, I missed the > bzr pull lp: but I tried a few other things but each time I got an > error saying virtually "you can't do that". However when I installed > bzr there was a box to tick for the Tortoise Shell (no pun intended) > which I ticked. > > After fiddling with direct calls to bzr I looked in files-tortoise > bazaar-update. This was real simple. I just entered the stellarium > folder and clicked update / OK and it did a checkout just like the svn. > > As a matter of interest I also went though the same procedure in > Windows 7 ultimate 64 bit on a dual core machine. No problem. The only > difference being the compile time was about half. Next I will try > Linux (in a virtual machine in Windows 7). > > The source code you see in stellarium when you click on browse bazaar > is probably just generated from the repo as required but I haven't > seen much direct access to this. > > Barry Gerdes > Beaumont Hills Observatory > S 33' 41' 44" E 150' 56' 32" > The repo is now in the '2a' format (was 1.x or something). I know the 2a format is much more efficient, and I'm sure my original download was about 330 MB - 160 now, as you got. I also no longer get the annoying, "Old version, converting on the fly, this may take a lot longer, change to new version!" messages. I still need to get my head around Bazaar's use of 'update' and 'pull' (every VCS is slightly different in terminology). You just need to be sure that the working files are being updated and not just the repo when you do your 'update' (if you're not making any local changes, I think both will work, but I need to confirm - anyone like to comment?) I am interested about your compile on Win 7 - was that on the same machine with no other changes? (I've been using Qt Creator, but my main gripe about it is build times, especially for incremental builds - the Borland compiler does it almost instantly). I should try the command line one day... Peter |
From: Barry G. <bar...@ho...> - 2010-06-20 08:47:48
|
Hi Peter I have a 6th computer dual core AMD 4GB memory etc that I built especially to use with Windows 7 ultimate 64 bit and VMware 7.1.0 So far I have installed it 6 times for various reasons due to crashes on three different HDD's, 2 SATA and 1 IDE. I have not got the same results twice. One would not run Qt creator, another would not load my network, Another would not run Tortoise SVN (64bit). Another would not run the VMware, Another just would not start plus various other problems with permissions that had to be organised. Windows 7 is a real dog! I think I have at last got an installation to go however. Keeping fingers crossed! On this computer I started from scratch with bazaar and did the full download 160MB. I compiled using MSYS as I have been doing now since I found I got easier results than from Qt creator. VMware works great now and I have virtual systems of XP, 98 and Linux Barry Gerdes Beaumont Hills Observatory S 33' 41' 44" E 150' 56' 32" Date: Sun, 20 Jun 2010 18:21:42 +1000 From: scr...@mo... To: ste...@li... Subject: Re: [Stellarium-pubdevel] O.k., now what? On 20/06/2010 14:52, Barry Gerdes wrote: Hi Peter Windows XP Yes I think the source code is reconstructed from the repo\packs (159 MB) as you say. I was watching the download and it got to about 160MB and then the source code suddenly appeared as the download stopped. When I got the source I had a look for ways to update, I missed the bzr pull lp: but I tried a few other things but each time I got an error saying virtually "you can't do that". However when I installed bzr there was a box to tick for the Tortoise Shell (no pun intended) which I ticked. After fiddling with direct calls to bzr I looked in files-tortoise bazaar-update. This was real simple. I just entered the stellarium folder and clicked update / OK and it did a checkout just like the svn. As a matter of interest I also went though the same procedure in Windows 7 ultimate 64 bit on a dual core machine. No problem. The only difference being the compile time was about half. Next I will try Linux (in a virtual machine in Windows 7). The source code you see in stellarium when you click on browse bazaar is probably just generated from the repo as required but I haven't seen much direct access to this. Barry Gerdes Beaumont Hills Observatory S 33' 41' 44" E 150' 56' 32" The repo is now in the '2a' format (was 1.x or something). I know the 2a format is much more efficient, and I'm sure my original download was about 330 MB - 160 now, as you got. I also no longer get the annoying, "Old version, converting on the fly, this may take a lot longer, change to new version!" messages. I still need to get my head around Bazaar's use of 'update' and 'pull' (every VCS is slightly different in terminology). You just need to be sure that the working files are being updated and not just the repo when you do your 'update' (if you're not making any local changes, I think both will work, but I need to confirm - anyone like to comment?) I am interested about your compile on Win 7 - was that on the same machine with no other changes? (I've been using Qt Creator, but my main gripe about it is build times, especially for incremental builds - the Borland compiler does it almost instantly). I should try the command line one day... Peter _________________________________________________________________ View photos of singles in your area! Looking for a hot date? http://clk.atdmt.com/NMN/go/150855801/direct/01/ |
From: Peter M. <scr...@mo...> - 2010-06-20 13:57:38
|
Barry, I've got a few more questions and would like to continue this conversation, but I don't want to pollute the mailing list any more than I've already done. Do you mind if I contact you directly? (You can PM me if you wish.) Thanks, Peter |
From: Thomas M. <tom...@go...> - 2010-06-22 23:44:01
|
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 On 20 June 2010 14:30, Peter Mousley <scr...@mo...> wrote: > Barry, > > I've got a few more questions and would like to continue this > conversation, but I don't want to pollute the mailing list any more than > I've already done. Do you mind if I contact you directly? (You can PM > me if you wish.) > > Thanks, > 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 > |
From: Thomas M. <tom...@go...> - 2010-06-22 23:46:31
|
PS: Forgot to supply some stats to show how the repo is shared between my 2 branches: thomas@percy:~/stellarium$ du --max-depth=1 58892 ./stellarium.dev 58892 ./stellarium.ngccat 162872 ./.bzr 280660 . On 23 June 2010 00:43, Thomas Morris <tom...@go...> 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 > > > On 20 June 2010 14:30, Peter Mousley <scr...@mo...> wrote: >> Barry, >> >> I've got a few more questions and would like to continue this >> conversation, but I don't want to pollute the mailing list any more than >> I've already done. Do you mind if I contact you directly? (You can PM >> me if you wish.) >> >> Thanks, >> 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 >> > |
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 |
From: Peter M. <scr...@mo...> - 2010-06-24 16:26:31
|
Just discovered... You can create a branch on Launchpad without actually going there - just: bzr push lp:~<USER_NAME>/stellarium/<BRANCH_NAME> Makes it very quick and easy if you want to share a branch with others. Peter |
From: Thomas M. <tom...@go...> - 2010-06-23 09:00:24
|
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 > |
From: Peter M. <scr...@mo...> - 2010-06-23 10:00:43
|
On 23/06/2010 19:00, Thomas Morris wrote: > 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 > In fact, the svn repo was up to about 6500. I'm pretty sure the difference is due to svn counting commits in all branches, but only the trunk was ported to bzr (and hence only it's commits have been counted). There are 4700 revisions in bzr. Here's a couple extra notes for a workflow: - when merging a series of commits, make the message description (not "merged fix") as, be default, it is all that will be seen in the log ('-v' will show the local branch commits that make up the trunk commits) - if you've got a bit to do in bzr, try 'bzr shell' - you can use 'bzr send' to create a merge directive (sort of a patch on steroids - merge like you would a patch/diff file) - there's always 'bzr uncommit'! |
From: Timothy R. <tr...@si...> - 2010-06-17 13:52:23
|
On Jun 17, 2010, at 1:44 AM, Peter Mousley wrote: > On 17/06/2010 13:21, Timothy Reaves wrote: >> On Jun 16, 2010, at 8:11 PM, Timothy Reaves wrote: >> >> >>> On Jun 16, 2010, at 5:23 PM, Timothy Reaves wrote: >>> >>> >>>> The switch was made to Bazaar. After using it some, I'm concerned it didn't bring any benefits, only omplexity, but, I'll wait and see. The big question is: now what? What is the workflow supposed to be? >>>> >>>> 1) Are we to create branches from the command line, or from the laucnhpad site? I created one from the command line, but there seems to be no way to link it to the stellarium site. >>>> >>>> 2) is each change to be in it's own branch? If not, there was no reason to switch from subversion, as we had branches there too. If so, what is the work flow for approving that branch, and merging to trunk? >>>> >>>> In general what is the intention of how we are to use any SCM for getting code into the app? I have two or three changes to the core, related only in that one or more plugin needed that support. I'm confused as to how bazaar is to help make progress in getting these changes reviewed, and in to trunk. >>>> >>> >>> I've scoured about all of the documentation I can find on LaunchPad about how they think branches should be used. What I've come up with is: >>> >>> *) create a branch >>> *) implement a single feature/bug fix >>> *) push it to LaunchPad >>> *) associate a bug or blueprint with the branch >>> *) recommend the branch for merging. >>> >>> Is this everyone else's understanding? Am I missing anything? Assuming it's basically correct, a question remains with where is the best place to create the branches. It can also get tricky if I have a branch, that has several other branches merged into it. This means that for the active branch to make it to trunk branch (isn't that an oxymoron?), they have to be merged in order, with none missed. >>> >>> Comments? Corrections? Rejoinders? >>> >> I've attempted a first go at how this workflow could work. I've created a blueprint here https://blueprints.launchpad.net/stellarium/+spec/stelobject-refactor-callback-to-signal , and I've associated with a brach that implements the refactoring. >> >> The branch was pushed to my own area in LaunchPad, trying to follow http://wiki.bazaar.canonical.com/SharedRepositoryLayouts#simple-developer-naming-project-joe-foo-project-barry-bar . On my local machine I have a shared repository created, and this makes each brach as small as it would be in SVN (about one tenth the size of a non-shared repository branch). When I pushed however, the full data was uploaded to ~treaves/stellarium/treaves1 . What I'll want to see if this makes ~treaves/stellarium a shared repository. If not, pushing braches is going to be an awful lot of data! >> >> I have proposed this branch for merging; see https://code.launchpad.net/~treaves/stellarium/treaves1/+merge/27791 . In general, I was thinking the work flow would be to re-use this branch after the merge is approved, or rolled back. This would be to limit the amount of data pushed. >> >> >> ------------------------------------------------------------------------------ >> 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 >> > > Do you have any hair left? It sounds like you've probably pulled it all > out by now... > > A distributed VCS is certainly very different to a centralised system > and there's a pretty steep learning curve. It will be worth it in the > long run, but I understand your frustration. It's more to do with the ever increasing number of SCM systems I'm forced to deal with, and each one being slightly different. CVS, SVN, Hg, git, Perforce, and now Bazaar, all being actively used. Perforce is nice, although there are a lot of g4 & v4 wrapper scripts written to make it somewhat easier to deal with. I understand the benefit of a distributed SCM, but also know most of those benefits are very subjective. If all we gain from the switch to Bazaar is local commits, then any one wanting them had them with git-svn. If our workflow on the hosting provider is the same, there was no benefit to changing from SVN. |
From: Peter M. <scr...@mo...> - 2010-06-17 14:23:41
|
On 17/06/2010 23:52, Timothy Reaves wrote: > On Jun 17, 2010, at 1:44 AM, Peter Mousley wrote: > > >> Do you have any hair left? It sounds like you've probably pulled it all >> out by now... >> >> A distributed VCS is certainly very different to a centralised system >> and there's a pretty steep learning curve. It will be worth it in the >> long run, but I understand your frustration. >> > > It's more to do with the ever increasing number of SCM systems I'm forced to deal with, and each one being slightly different. CVS, SVN, Hg, git, Perforce, and now Bazaar, all being actively used. Perforce is nice, although there are a lot of g4& v4 wrapper scripts written to make it somewhat easier to deal with. > > I understand the benefit of a distributed SCM, but also know most of those benefits are very subjective. If all we gain from the switch to Bazaar is local commits, then any one wanting them had them with git-svn. If our workflow on the hosting provider is the same, there was no benefit to changing from SVN. > > I'm not arguing for or against the choice of using bzr. And I certainly share your feelings about having so many tools (and let's not start on perl/python/ruby/js/...). But one problem of using svn publicly but git-svn or bzr-svn locally is that everyone ends up using something different and it is more difficult to collaborate. And regardless of the format of the main repo on LP, bzr offers the ability for everyone to easily create and share branches (with user pages on LP or otherwise). So if everyone is going to be using something like git locally, why not just use git/bzr/hg? Again, I'm not arguing for or against any particular choice, just trying to help with some info (although I wasn't much enjoying have to deal with svn when using git). I do have some changes I'd like to propose for Oculars, so perhaps that will be an opportunity for you to get a warm, fuzzy feeling about using bzr. |
From: Matthew G. <mat...@gm...> - 2010-06-17 20:48:26
|
I also imagine a workflow close to SVN for committers making fixes and small-ish changes, with local branches for larger / experimental changes and non-committers. I'm pretty new to DVCS. The reason I like bzr is that it is (at least superficially) similar to svn in usage. I too do not like to learn new tools when I have one which works ok. Being able to make a local branch and commit into it makes it worthwhile for me. I did try bzr-svn and liked it but I feel more comfortable with this workflow now we have switched fully. Branch management is going to become more of an issue that it has been. I think that we are getting to the stage where we will be ready to make a 1.0.0 release in the not too distant future. After this time we really need to think about having multiple branches, with important fixes being backported into the stable branch (maintaining API compatibility for plugin developers and script authors), and new features being developed in different branches. Version numbers after 1.0.0 should mean something in terms of API / ABI compatibility. Matthew |