Sign in to follow this  
MatrixCubed

Repository Management

Recommended Posts

Excuse me if this is posted in the wrong forum, but it seems at least mildly appropriate :) The project I'm working on has taken a step toward "larger", and as a result, other developers have come into the fray. I have configured a repository for us to use for the project, and everything is working just great. The problem I am having is grasping how the 'bigger picture' of project file management should work. The project is open-source, so anyone can obtain a copy of the source-code from the repository. The few devs that there are each have their own read/write accounts in order to be able to commit their changes to the project. But the question in my mind is, what happens when the repository source doesn't match what any given developer has on his workstation? For example, Coder A makes a change to file.cpp, and commits it to the repository. Coder B later makes some changes to his local copy of file.cpp, then tries to commit the changes. What is the expected result? Will there be a version conflict, and Coder B is responsible for merging file.cpp into one cohesive resulting file? Should he be updating his source before working on code? What happens if two coders are working on various files simultaneously? What is the best solution for managing the project files? These questions weren't easily answered by the server documentation I have been reading through in order to configure the server software, so I figured I would ask elsewhere :) If it makes a difference, we are using Subversion for the repository. Thanks!

Share this post


Link to post
Share on other sites
Depending on your SCM system, it will raise a conflict message.

Some Subversion clients allow you to heal the conflict or overwrite either version of the file. Whoever is checking it in is responsible for healing the conflict. You might be able to abort the checkin, dump a patch, revert, and restore the patch depending on the extent of the changes.

However, I highly recommend keeping your source files granular enough (and your checkins/updates frequent enough) that several developers won't step on each others' toes.

Share this post


Link to post
Share on other sites
the normal rules for CVS / Subversion is:

1. Each person to commit is responsible for the quality of there checkin.
2. Last person to commit is responsible for the build still working and merging any files which conflicted.

Therefore you run an unpdate prior to a commit. Depending on source control system you sometimes need to make sure your command line flags are set correctly to do what you want.

I did a small-medium project recently using hosted subversion. I was the only one who really understood how to use it (because the other two had never even used CVS) so when merge problems arose, I had to interceed on their behalf (after an email / phone call). Over a 6 month project I only had to do any custom merging 3 times, and had to do some replacements about 3 times as well. Total time spent on merge fixes and verification about 4 hours over the life of the project (after the first one which took me 2 hours to learn the commands correctly).

Subversion won't even let them accidentally check in before doing an update (if the repository changed) so it keeps people from overlooking these types of conflicts and just blasting each other's stuff.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this