On 28-4-2011 16:31, Tommaso Cucinotta wrote: > Il 26/04/2011 20:14, Julien Rioux ha scritto: >> I don't feel the need to move to git. At all. > > I'm seeing 2 discussions merged, in this thread: > 1) what development model to use (how many branches, what & how often to > commit where, what & how often to release, etc.)
The first two are however not really related to the third one. > 2) what development tools to use to implement (the proposed changes to) 1). > > AFAICS vfr is actually asking for a lower number of merges into trunk, with > more testing made on alternate experimental branches, till the features are > rock stable, then merge them as a single (or a reduced number of) commit. > AFAICS, this can be done with svn as well as with git. > While I can share his viewpoint, as he's going through all of the patches (!), > I also suspect this will lead to a lower number of developers having the > chance > to try a feature before the merge into main trunk, because it's being > developed > in an alternate branch, and I'm not sure everybody wants to download and > synchronize tens of other branches, with all the burden for compiling each one > of them (unless you have a 48-core over which to do that). As I pointed out somewhere in this thread already, the idea is that all feature branches are really regularly merged together (daily, hourly, or even after each commit). This means that there will be one branch which contains all features and will be approximately equal to current svn. As I also wrote is that I have collected the commit of last two months and I categorized them in 60 feature branches (ok more than the 20-30 I mentioned earlier, but lots of them do not really deserve to be still in a feature branch). Now, I can merge them all together in _1_ octopus merge and after this merge, it is exactly equal to the current trunk. To conclude: if you use this branch, you can test all new features in exactly the same way as we do now. This only requires 1 fetch, 1 merge and 1 time compiling. > Concerning the fragmentation of a feature into multiple patches, I'm > suspecting the point is not actually in svn vs git, but rather the key > is in the proper use of other tools (e.g., quilt or who knows what > else) which help in "managing patches". Git can really help you out here. You can reorder, squash together, split, reedit the commit log as many times as you want, before the final merge in the stable trunk branch. First of all, you are working locally and you can prevent the most stupid errors before publishing it to the rest of the world. Though, it is advised to share your produced code as quickly as possible (not that quick that everyone will see your stupid errors though). Secondly, after you have pushed your feature onto the web, you can still edit the commits. You can correct typos, you can listen to other people's comments, you can polish it in the meantime. Then you restructure the commits: that is you - merge together a typo correction with its original commit, - etc. After this, the feature can be nominated to be merged into trunk- stable, and you have a well structured series of patches. This will help the review of others as well as future developers crawling through history, as well as yourself because you may find some errors yourself when you clean up your patch series. > > So, I wish it could be clarified to other developers: > -) what model do we want to switch to -- concerning 1); > -) what advantages would git actually bring in the loop I tried to make that clear in the above. -- concerning 2) -- but especially what other tools would it be necessary to learn. git. I will write a manual how to shape your patch series effectively. Vincent
