CODEWITHSUNDEEP
svn
Iraimbilanja
Iraimbilanja

Reputation:

Efficient micro-cooperation with team members in Subversion?

Sometimes I'm working on a feature and hit a weird crash or something else I can't immediately solve. Then I wanna give my current source code to the guy next to me so he can also try solving it.

Seems like I have 3 bad options and 0 good ones?

What's the standard way of handling this in Subversion?

Also: would DVCS tools like git handle this seemingly simple situation better than Subversion?

Upvotes: 2

Views: 270

Answers (4)

Jeff Dallien
Jeff Dallien

Reputation: 5101

If the other person really is sitting next to you, might I suggest pair programming? They can come over to your computer and you can work together on it. It can be very effective and when you're having trouble, you don't have to work in isolation.

That being said, even with pair programming sometimes you've got to send code to someone else that isn't ready for trunk. Other than the typing involved, there's not much to creating a short-lived branch in subversion, and some small scripts will automate a lot of the process for you.

Here are two scripts that work for me. They assume a repository structure like:

project/trunk/
       /branches/some_branch
                /another_branch

Some adjustments would be required to work with another structure.

# script 1: svn_wc2b (working copy to branch)
trunk_url=`svn info | grep URL | sed 's/URL: //'`
project_base=`svn info | grep URL | sed 's/URL: //;s/\/trunk.*//'`
branch_name=my_working_copy

svn cp $trunk_url $project_base/branches/$branch_name -m "Creating temporary branch for working copy."
svn switch $project_base/branches/$branch_name

Then when you want to share your working copy of trunk, you would type:

svn_wc2b  # creates branch, switches to it    
svn commit # commit your in-progress work to the branch

To get your code, the other developer just needs to type:

svn switch http://repository/project/branches/my_working_copy

When the other developer is done and has committed changes, use a script like this:

# script 2: svn_b2wc (branch to working copy)
branch_revision=`svn log -q --stop-on-copy | grep '^r[0-9]' | sed 's/^r//;s/ |.*//' | tail -n 1`

if [ -e $branch_revision ] && [ -e $1 ]
then
  echo "Couldn't get branch creation revision number. Check svn log --stop-on-copy and use svn_b2wc <revision_number>"
  exit
elif [ -e $branch_revision ]
then
  branch_revision=$1
fi

branch_url=`svn info | grep URL | sed 's/URL: //'`
project_base=`svn info | grep URL | sed 's/URL: //;s/\/branches.*//'`
branch_name=my_working_copy

svn switch $project_base/trunk
svn merge -r $branch_revision:HEAD $branch_url .
svn delete $branch_url -m "Deleting working copy branch."

From your directory that has been switched into your branch, you type:

svn_b2wc # switch back to trunk, merge branch changes, delete branch

The code changed in the branch is now back in your working copy of trunk and you can continue working until you are ready to commit. It may seem like a lot just to share some code, but if you spend some time automating your processes with scripts then it will only take seconds each time you need to use it.

Upvotes: 0

Philip Reynolds
Philip Reynolds

Reputation: 9402

The problem with subversion (and I say this as a day-to-day user of it) is it doesn't promote the idea of checking into source control early and often. Because of centralised branches, generally noone checks in until the code is "ready" (air-quotes). When working with small teams previously I have created per-user branches in Subversion. So your repo might break down as follows

/
`---> trunk/
`---> branches/
`---> users/
            `---> john/
                      `---> trunk/
                      `---> branches/
            `---> mary/
                      `---> trunk/
                      `---> branches/

It can start to get a little messy with subversion and I'm not sure how effective it is when it comes to large teams. SVNmerge can help with some of the problems, but it might be one possible solution to you. git (and in general, most DCVS') can eliminate most of these problems which is one of the reasons for their popularity.

Upvotes: 1

JMD
JMD

Reputation: 7377

I ususally take the expedient of e-mailing (or otherwise transferring) the offending code over to my co-worker, assuming s/he doesn't have changes in that unit (or those units) that can't be temporarily shuffled aside. S/he then copies my changes into place and goes to work. Nothing more or less than that. Later, when they do a diff they see my changes in their diff, update from the repository to overwrite my code they helped with, and voila. All back to normal.

Upvotes: 0

Greg Hewgill
Greg Hewgill

Reputation: 993471

I've done this in the past using the send-a-patch method. However, it becomes difficult to reconcile the changes later.

I now use Git, and it definitely helps with this situation, it's a very natural thing to do. I can have a cow-orker pull specific commits from my repository and help work on them. We can each make commits, then I can pull the commits from their repository, use git rebase -i to organise everything, and proceed from there.

Upvotes: 1

Related Questions