its because of the stability reasons why people usually start think about
some branch and not just trunk. to impose levels of bureaucratic controls
on trunk ...
I don't know why you think I want to impose bureaucratic controls.
Just because I want to propose to have a stable trunk branch which
will only acquire features that are 'finished' or don't show any
regressions and which have a proper organized commit log.
...looks like some NASA project and not our lyx hobby kitchen.
It's rocket science to have a two-stage process ? Not like I
propose really complicated stuff, just a two-stage process.
1) a new feature is merged into development, 2) the feature
has shown to be finished, stable, etc. and will get merged
into trunk-stable which will be the release.
it really matters what exact review scenario do you propose. there was time
when anything needed big boss Lars OK to go in. at the end the frustration
of other devs errupted so trunk was opened more closer to nowadays situation
where small set of people are freely allowed to push things into trunk
and its up to their intuition whether its enough problematic to ask or not.
Did I say that I want you to ask my permission before committing
something ?
it looks like that the old "one patch" per "one feature" and "wait for
my review,
Did I say you have to wait for my review ?
i'm just little busy right now" monster emerges just under
different name, god bless branching kingdom :)
So, what if the person maintaining trunk-stable would be busy.
Why would you care when your feature gets merged exactly into
trunk-stable ?
it didn't work and i'm against moving back to the old kind of situation,
if thats what you propose.
Please read the other threads on what I do propose.
so it boils down to the question whether the movement of code through
these layers is evoked by "this code didn't caused bugs yet"
or by "please changes this this and that and when i'm happy/finished with
review it can go".
Well, it should not be too much to expect some proper code
before pushing it into the release.
Why is it an annoyance ? Create a branch, commit your stuff and push
the branch.
when there is some small fix then i simply push it into trunk and dont want to
keep in mind when-where to merge something and even more ask about somebody
permission whether these lines please him in order to merge.
Did I say you need to ask permission ? Did I say you need to wait before
doing something ?
Even the smallest fixes appear often to be either wrong or incomplete. If
it is really a small fix, it will move through the layers quickly anyway.
When using git, you have to create a new branch anyway
whenever you do some coding yourself, so that the original branch
can track the remote branch easily.
no i can just stay in small-bugfixes branch, which will be automatically
merged once a day.
Such a branch is useless.
#ah I made a typo
the problem is that you never know when or whether this situation come.
Often this happens quite quickly, either you realise it yourself or some
fellow developer reminds you.
if you wait too much you will spend your time on resolving the conflicts
and you need to carry in your mind what needs to be pushed.
You somehow think that you need permission before pushing a feature ?
so where is the trigger that small thing should be merged into the common
tree?
I don't know what you mean by the "common tree" ? If you mean merging
a feature into development, that would be the same as the trigger
that makes you commit something to svn trunk. If you mean merging
with trunk-stable, that would be when the trunk maintainer feels to
clean up the list of branches that need to be merged.
Vincent
