On Tue, Oct 9, 2012 at 7:49 PM, Zoran Vasiljevic <z...@archiware.com> wrote: > > On 09.10.2012, at 20:10, Jeff Rogers wrote: > > Hi Jeff! > >> Propose >> changes on the development list and then make changes to the main > > This is how we have worked so far. This mostly covers bug fixes. > Whole-sale changes are little bit different... but they happen > seldom. In that case, a branch consisting of all the changes is > prefered.
Conceptually yes, but don't actually use a mercurial branch for temporary development. You can't delete branches. On your local computer just clone an existing checkout into a new directory, it'll use hard links so it's fast and efficient. If you want to publish it for feedback then click the 'fork' button on the naviserver project at bitbucket and create a new repo under your own account: push your changes directly to it. If it's a small change, just post it here. Anyway, if you think of vc as backup and approval then it sounds like a drag, but it's really more like your editor - it helps you code. You often don't know what you're going to end up with when you start so you use your editor and hg to manipulate the code. - You start to add a feature but half way through you realise if you refactored some existing functions it would make the addition easier. - So, pop-off what you've done so far, refactor the code, push your pending changes back. - Then you notice a bug in some existing code. Pop off both changes, fix the bug, push them back on again. Now when you share the code there's 3 separate changes and they tell a story: here's a simple bug fix, here's a refactoring which should not change existing behaviour, and here's a new feature. The easier it is to read the more people are likely to read it and the more feedback you'll get, which is invaluable. In addition, everyone who touches the code end up with a mental model of how it works, so when the code changes the model needs to be synced up again. It's not scalable to have each person slog through a big old dump of code that took the original changer 6 hours to grok. You need to present it like a story so it makes sense. Check out the lkml to see how the ninjas do it. ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
