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.