1

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?

Kevin
  • 731
  • 1
  • 4
  • 15
  • Of course, we're hoping that the client will let the team create new branches. – Kevin Sep 16 '14 at 15:54
  • You really should use `git` – Basile Starynkevitch Sep 16 '14 at 15:55
  • 4
    possible duplicate of [To check-in small chunks and frequently, or to check-in large chunks but infrequently](http://programmers.stackexchange.com/questions/96302/to-check-in-small-chunks-and-frequently-or-to-check-in-large-chunks-but-infrequ). In a word, they're doing it all wrong: what they need is to [Commit early, commit often...](http://programmers.stackexchange.com/a/96306/31260) - into that very branch that was given to them by client – gnat Sep 16 '14 at 16:06
  • 5
    One important thing: Branches in SVN do not take up extra space. ["Subversion's repository has a special design. When you copy a directory, you don't need to worry about the repository growing huge—Subversion doesn't actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree."](http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html) – Alan Shutko Sep 16 '14 at 16:26
  • Really, they are arguing about a few gigabytes? 10gb of space costs what $0.50 these days (On a bad day) – Zachary K Sep 16 '14 at 16:44
  • Enterprise costs are higher (although I think enterprises bring it upon themselves). Our TCO cost for SAN is $7/GB. – Alan Shutko Sep 16 '14 at 16:50
  • @Zachary I would be surprised if the client tells us we can't use more branches. I'm asking this question on the off-chance that they say no. – Kevin Sep 16 '14 at 17:04
  • 2
    Even at $7/gb vs dev time, who cares – Zachary K Sep 16 '14 at 17:07
  • 1
    @gnat I don't think this question is a duplicate of the one you posted. That one asks when to commit. Mine asks assumes we'll commit regularly and asks what to do if we can't branch for business reasons, which the question you linked doesn't address. – Kevin Sep 16 '14 at 23:32
  • http://meta.stackexchange.com/questions/194476/someone-flagged-my-question-as-already-answered-but-its-not – gnat Sep 17 '14 at 07:04

2 Answers2

5

"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.

Idan Arye
  • 12,032
  • 31
  • 40
  • 3
    Sounds like a great case to use git-svn as a bridge between the two systems, and then use Plain Old Git amongst yourselves. You would have one "Merge Master" or "Benevolent Dictator" who merges Git branches and `dcommit`s them into SVN. – Greg Burghardt Sep 16 '14 at 16:30
  • @GregBurghardt I don't think the term "Benevolent Dictator" fits here - unless you suggests the Merge Master always get the final say in what gets in and what stays out... – Idan Arye Sep 16 '14 at 21:41
3

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.

eli
  • 131
  • 2