when we were still over at the other site threads from october 2005 - it was agreed upon that the trunk was the STABLE RELEASE point and the branches were the UNSTABLE stuff ... now if that is true then why is this comming up yet again!!! this was one of the reasons there was a loss of personel from the old site... please!!!! lets not do this again!!! please!! (insert begging on knees smiley here...)
# [Fri 02:08:50pm] imo wz need a new branch to test changes...
# [Fri 02:09:18pm] currently branch and trunk are somewhat inverted...
# [Fri 02:11:34pm] huh?
# [Fri 02:12:24pm] currently branch has the functionalities of 'trunk'(features of the new release and relatively stable)
# [Fri 02:12:49pm] while trunk has all unstable factors and wont affect next release much
# [Fri 02:13:01pm] this is as it should be
# [Fri 02:13:12pm] trunk is the mainline for development (ie unstable)
# [Fri 02:13:32pm] stable branches are kept for minor releases (for bugfixes)
# [Fri 02:13:52pm] think of it as a tree and you'll see why the imagery fits
# [Fri 02:14:58pm] actually I think using a branch to do releases is quite unusual
# [Fri 02:15:57pm] i'd like to see where you have that notion from, because all my experience with branches and cvs/svn says otherwise
# [Fri 02:18:51pm] just like in a tree, branches fork off the trunk and then bifurcate further with smaller 'releases', while larger 'releases' come off the trunk
# [Fri 02:19:07pm] that is why the metaphor is used
# [Fri 02:19:17pm] Watermelon2: I have the exact opposite experience with SVN (i.e. usually branches are being used to stabilize the source base)
# [Fri 02:25:31pm] but trunk should be stable...or noone will be able to do further changes based on it...
# [Fri 02:25:48pm] trunk is like a shared development branch for all developers
# [Fri 02:26:11pm] to avoid the overhead and negative effects of branch per developer
# [Fri 02:27:03pm] yes, trunk should always work
# [Fri 02:27:17pm] nobody should check in stuff that breaks trunk, and if they do by accident, it should be reverted
# [Fri 02:30:25pm] Watermelon2: if you prefer something like a branch per developer you have an entirely different revision control system, something like GNU arch or monotone for example
# [Fri 02:31:32pm] and as for "trunk should be stable", it depends on what you mean with that of course, if you mean that it should always compile on every developer's system I agree
# [Fri 02:49:21pm] by 'stable' I mean it shouldnt be flooded with unpredictable massive changes in multiple files
# [Fri 02:50:48pm] if you want to have your work undisrupted, just don't "svn up" for a while
# [Fri 02:51:18pm] but in my experience, it is better to merge earlier and often rather than later
# [Fri 02:51:36pm] but my changes will undo their changes if i dont merge earlier
# [Fri 02:51:47pm] and noone wants his changes to be undo'ed
# [Fri 02:54:11pm] i don't understand
# [Fri 02:54:33pm] if you undo someone else's changes, you are doing something wrong, i would say
# [Fri 02:57:44pm] not really sometimes functions have completely different functionality after a commit and you will have to bin the changes you made,or it will 'override'/undo the changed functions
# [Fri 03:01:53pm] then the devs should probably communicate better about what they are massively rewriting at the moment
# [Fri 03:02:37pm] the key is to keep your patchsets as small as possible, and commit as frequently as you can, to avoid massive conflicts
# [Fri 03:02:54pm] giant patches are bad
# [Fri 03:03:18pm] but sometimes unavoidable when implementing something that requires a massive change
# [Fri 03:03:21pm] but then again coordination is key
# [Fri 03:03:25pm] that is true