Judah Frangipane wrote:
We have a setup similar to yours. We keep all AS in external files. We still have trouble merging changes from other developers. How do you handle when TortoiseSVN doesn't merge the changes? Have you resorted to locking the files or setting up a linear development structure?
We very rarely lock files (I can only remember one instance where we did that), though our typical practice has been having individual developers "own" different parts of the class tree and hold primary responsibility for their classes, although other developers can and do contribute to and make changes in those packages as well. This tends to minimize the need to do manual merges, though it doesn't eliminate the need. As an added benefit, this approach also helps keep difficult manual merges in the hands of the developer who best understands the particular class (as I'll describe later on).
In my experience, following good object-oriented coding practices and deciding upon our APIs well in advance have helped us to minimize drastic changes to our code of the sort that necessitate widespread manual merges. We also have a tendency to pass our data between packages and applications using transfer objects. This helps to reduce dependencies between major packages, even within a single project, and allows us to develop more independently in our own spaces while still keeping things relatively easy to integrate.
In practice though, we do occasionally run into situations where SVN cannot automatically resolve merges, so we merge by hand when we need to. Fortunately, this isn't too often, and many times the differences end up being just debugging traces.
For truly horrendous changes, say refactoring a package of 20 or so classes, I'll typically work on my own branch until I'm done before trying to reintegrate it into the trunk to spare everyone else the grief of dealing with it all. However, this isn't to say that it's fun. What it does do though, is to keep the need for manual merging of code and testing of the new changes restricted to one person and in a single go rather than spreading among multiple developers with possibly different levels of familiarity with the code.
On the flip side, when I would like to make changes to code that I'm only very marginally familiar with and which some other developer "owns," I've found it helpful to either consult with the owner first (via instant messaging or in person), or send them a patch with my proposed changes (and working locally with my changes for the time being), letting the "owner" validate and check the changes back into the trunk, making any manual merges as necessary.
Having worked with source control systems of both the locking (Microsoft Visual SourceSafe) and the merging (CVS and Subversion) varieties, I must say my preference has been toward the latter. Although having to occasionally manually merge changes does take time, I've found that for me, especially when working in a large and/or geographically distributed team, the merging model is more efficient than waiting upon locks being released and then making changes, and particularly so if you can have the difficult merges done by developers who can "own" and understand their parts of the class tree.
Jim _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
