Brad I'm completely with you on your process how to handle working
copies. I introduced this process with quite a large software
development team earlier and this is the best approach IMO.
But what can one do if developers are used to work different...they work
like I described it - they won't change the way they work because "it
worked in CVS like that"
see a few comments inline (representing the developers, not necessary my
opinion):
On Thu, 2007-03-15 at 10:23 -0400, Bradford Smith wrote:
> I cannot comment on whether the behavior you are seeing is a bug or
> not, but I do think you're probably making life a lot harder for
> yourself than you need to. The subversion switching feature is nice,
> but easily overused and abused. I think you'll find it much easier to
> avoid problems both now and in the future if you follow these
> self-imposed rules:
>
> 1. Commits and checkouts are always done on the ENTIRE trunk or
> branch.
>
> Individually checking in files or subdirectories is just going to give
> you headaches in the long run. It's easiest if you think of the
> entire tree a unit and treat it that way.
There are changes inside the tree a developer doesn't want to publish to
others...so we selectively commit single files, folders as we like.
Sometimes developers commit 20 times (20 files) within minutes.
This almost makes merging impossible (start rev - end rev.) because you
can't tell what the changeset is...
> 2. Never switch portions of a directory tree.
>
> I know the SVN book talks about doing some nice tricks by switching
> parts of your directory to different branches, but this way lies
> madness. It's too easy to forget that you've done things like this.
> Also, it makes crazy things happen when following rule 1.
At least that's not a thing the developers do.... :-)
> 3. Commit logically separate changes separately.
>
> It looks like you were trying to follow this rule, which is good. It
> will help you lots in the long run when you need to merge some, but
> not all, changes from one branch to another.
See above...they use synchronize view in eclipse and commit/update
single files.
Statement: "the repository isn't the "master" there might be multiple
"masters" in the working copies of the developers"
IMO this means every developer has his own branch :-)
> I suspect you ran into the problem you describe because you got part
> way through making some changes on the trunk and discovered a bug you
> needed to fix on both the trunk and a branch. The following procedure
> would serve you much better:
>
> 1. check out a fresh copy of the trunk in another working directory.
> 2. Fix the bug there and check it in with appropriate comments.
> 3. switch the new working directory to the branch.
> 4. merge in the change you just made to the trunk and check in the
> branch.
> 5. either delete the new branch directory or leave it around for
> convenient use later.
> 6. go back to your original trunk working directory.
> 7. do svn update to get the changes you just checked in.
> 8. resolve any conflicts and continue with your original work.
I didn't run into the problem, the developers did. I just try to find
workarounds for their stubborn way to do things :-)
But a few things why the above doesn't work:
1. with a 900Mb trunk this isn't funny...takes too long. Especially if
people dont call "update" on the whole directory but do it selectively
(synchronize view in eclipse e.g.)
3. switching the 900Mb working copy (with local changes that weren't
commited) is a pain ... and leads exactly to what i described
5.+ 6. two working copies means two projects in their IDEs they can't
live with that...
To sum up it's not easy to get Software Developers that have a certain
way to do things, do it better with Subversion principles.
Reinhard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 16 10:31:42 2007