Re: Subversion tagging

Byron Brummer wrote:
>> *Usually* one would do this by fixing the one file on the branch,
>> rather than using the trunk for such things.
>
> Create a branch, make one fix.
> Create another branch, make a different fix.
> Create another branch, make yet another fix.
>
> Is this the pattern you're advocating?

Nope:
     Create a branch, i.e. this version is now "stable."
     make a fix on the branch, sync to server.
     make a fix on the branch, sync to server.
     ...

In the meantime new feature development is happening on the trunk, which
by definition is not guaranteed to work as a whole, not even per file. ;-)

This may not be as nice if you want to check out "version with bugfixes
A and B but not C", but it's good for this sort of small-fix scenario.
If you did for some strange reason end up wanting a strange combination
of bugfixes you could probably do that by asking for a specific revision.

> Additionally integration is pushed down the road, greatly increasing the likelihood of
> issues which again increases the overhead as well as risk.

There is a small amount of overhead but I wouldn't call it huge. You
would have to commit the fix to the branch and the trunk at the same
time. I do this all the time anyway, even at work for what you call
"shrinkwrap" stuff (we use CVS at work... although will be switching
soon hopefully.) Double-committing changes only becomes an overhead
worth mentioning if the branch happens to be significantly different
from the trunk. When they're the same, it usually just means copying
the file.

> Back in the real world we find that 99.9% of changes are small,
> isolated, and don't mingle with other changes happening at the
> same time. Branch per change or similar is to argue that you
> should plan your entire process around the most unlikely of
> conditions (the 0.1% of times you'll clash). -I'm speaking
> with my own bias right now toward web based applications.
>
> Again, you're in a shrinkwrap lifecycle with a traditional
> process

I fail to see why you make this assumption about my development cycles
when I haven't even mentioned the kind of work I do.

In case you actually care, my work is around 90% web application and 10%
common code. For the web applications I generally keep two active
branches - stable and the trunk. The stable one I manage as previously
discussed -- make a change, commit it, sync it to the server. It has
worked for some time now, actually...

Daniel

-- 
Daniel Noll
Nuix Pty Ltd
Suite 79, 89 Jones St, Ultimo NSW 2007, Australia    Ph: +61 2 9280 0699
Web: http://nuix.com/                               Fax: +61 2 9212 6902
This message is intended only for the named recipient. If you are not
the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
message or attachment is strictly prohibited.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org