I’m a computer science TA working with some students in a senior capstone course (effectively, a consultant for a small team). I met with them to discuss how to use version control, and they’re in an interesting situation:
Their current practice to to complete their tasks on their own machines without committing. Then, at the end of an agile sprint, they all commit their work to the same branch, figuring out merge conflicts along the way. I suggested that they each create their own personal branches and commit to them more frequently, whenever they’ve completed a task, and then merge the branches at the end of the week.
However, they’re working on the project for a client who is hosting the repository on his own server. The project already has dozens of branches, each of which takes up several gigabytes of space. (The team has been told to work in a particular branch, not on trunk.) As a result, the team will probably need permission from the client before they can create new branches, and they might not get that permission.
If the client tells the team not to use branches or takes a while to respond to them, how should they proceed? What are some reasonable SVN usage patterns when a team can’t create new branches?
10
“reasonable SVN usage patterns” is an oxymoron.
You can’t create more branches on the client’s server – that’s the client’s rules and they should be respected. At any rate SVN is not built to handle many small branches(or any number of branches that’s bigger than 1), since they’ll remain in history forever and since merging them all the time will be a pain.
If this was Git – while still having the one-branch rule – you could utilize Git’s distributed nature and host your own server. The students will push to that server, merge the branches on that server, and at the end of the sprint organize everything and push it from the University’s server to the client’s server. The University’s server will be the place where all the branching-merging mess happens, and the client will get their commits in a clean single-branch like they want.
Unfortunately, this is not Git, so you can’t do that. Or can you?
There is a tool called git-svn that allows you to push and pull from Git to SVN. It’s not as good as pure Git, but it should be enough for your to push from the Git repo you’ll host on the University’s servers to the SVN repo on the client’s server. So, your students will work on the Git server with all it’s branching and merging goodness, and at the end of the sprint, after they rebased all their work to a linear chain of new commits(so SVN could handle it), they use git svn dcommit from the University’s Git server to push their changes to the client’s SVN repository.
2
As much as I hate answers on SE that are ‘do it a way differently than you are,’ since they’re not a real answer to the question, I think that has to be the answer here.
The workflow you described is a distributed version control system, such as git or mercurial, whereas subversion is a centralized version control system. The two share a lot of similarities, but have some fundamental differences as well. Trying to shoehorn that workflow into subversion is like trying to jam a square peg into a round hole, and is going to end up causing as many problems as it solves.
Either you need to get the students to adopt SVN’s religion, or use a distributed version control system among yourselves, and push to the client’s system separately.