The problem I have is this.. We have a team of VB developers working
on a large, newly-released project. We also have a team of support
guys that handle phone support for this project. The support guys are
hacked off at the VB developers because they are not separating
bugfixes from new feature additions in the code. They work off the
same codebase. So, one guy fixes a bug, but another guy adding a new
feature will break something else. Because they're working off the
same codebase, they have to release patches off the broken code. It's
a mess, and an ideal situation for proper version control.
My original plan was to train them on subversion, having them create
feature and release branches, and merge when necessary. This would
allow them to stabilize a release branch, only merging bugfixes back
in to the release. New features would be segregated in feature
branches, and merged back into the trunk to be added to the next
release.
So, without branching/merging what I'm gathering is, you guys would
assign *forms* to specific people, and let them be the only ones to
manage those forms. They would have to manually keep separate copies
of the forms based on whether or not they are working on a bugfix for
a current release, or adding new functionality for the next release.
If I go with this, would there be a better way to setup the repository
layout other than the standard "/branches", "/tags", and "/trunk"
directories? There would be no branching/merging, so should there be
directories for each developer maybe? "/dev1", "/dev2", etc?
On 6/27/05, Simon Large <slarge@slarge.plus.com> wrote:
> Brass Tilde wrote:
> > If something like that *is* necessary, Subversion's locking feature
> > should suffice to keep the two in sync, as only one of them
> > would be able to lock the form, and its associated FRX, at the same
> > time. It believe there is a property to which Subversion is
> > sensitive that tells the client that a file must be locked before
> > being edited. You could set that property on all of your forms
> > that have FRX files associated with them, along with the FRX files,
> > of course.
>
> Locking will prevent 2 developers changing the same binary file (both
> working on trunk), but it cannot stop one changing it on trunk and one
> changing it on a branch. Once that happens you have an un-mergeable
> situation.
>
> Simon
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.tigris.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
> For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Jun 27 17:48:54 2005