On 07/03/12 04:03, Steve Bennett wrote: > checkout code > add a feature > update - nothing new > commit > add a feature > update - merge > commit > ...
This is not the way you work with subversion. You usually do: checkout code add a feature commit add a feature commit Sure, occasionally the commit will fail due to a failed file, so you svn up, verify it's been correctly merged and recommit. But it's a uncommon case. > You do: > > checkout code > create branch (or however you will do it here) > add a feature > commit/push > checkout master again... > > In other words, you don't think of adding new layers of code to a > single monolithic code base, you think of sending individual, > independent packets of code to be combined in some order. I don't think about changes as "adding to a monolithic code base". In a linear development there is a clear way on how they are combined, but the author probably know how it could be. In git, you have the same thing, but with more ambiguity when you need to specify from which revision you develop it. Too young, and there is the risk you're depending on a parent which can get rejected. Too old and you miss new changes and it may not apply. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
