0

I have previous experience with git but is a newbie to Subversion. I am tasked to set up a repository for my team but is not sure how the best structure should be. (suggesting me to go back to git won't work here because i am pretty much stuck with subversion, but i appreciate your honest advice!)

Let say i have three developers(Sam, Tom, Bob) on my team, each of them need their own branch for development(and they commit to their own branch so they can keep track of their own changes and revisions. I see this as a workaround for the fact that subversion does not have local commit capability like Git does. Commit in subversion is equivalent to push in Git.). After that, they push their changes to Test then production. Here is the structure i have in mind: 

MyProject
   /trunk
         /MyProject
   /branches
         /Test
         /Sam
         /Tom
         /Bob
   /tags

Here is the workflow: At the end of the day(or during the day), all developers pull changes from the test branch and then push their changes to the test branch and resolve conflicts if need. For the production update, MyProject in trunk will merge with the Test branch.

Let's assume that developers push their changes to the test branch regular enough that an attempt to merge won't cause a disastrous conflict.

Questions:
1. Is this a good structure for subversion team project?
2. Is it possible to point the root of the developers' branches to the test branch? So when VisualSVN/Update is clicked, the developer branch will automatically update to the head of the test branch.

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
CYC0616
  • 645
  • 3
  • 9
  • 14

1 Answers1

0

Just (chaotic) thinking

  • In /trunk MyProject is excessive node (just because repository is exclusively for MyProject)
  • In per-developer+stable(trunk)|unstable(Test) branches you'll get a lot of merges (thus - can be victim of "Merge Hell" at any time: you can try to avoid contextual conflicts, but Tree Conflicts during bidirectional merges between development branches wait you)
  • "End-day Nightmare" (merge to Test + merge from Test) will require a strong discipline and attention and accuracy (and time)
  • For short-time tasks (solitary commits) "shared branch" may be somehow better
  • "Branch Per Task" instead of "Branch Per Developer" give more understandable tree of repository and manageable development+release (with short-term branches, related to tasks, PM|TL can monitor state at any time - compare it with "forever" developer's branches). But it will not (must not) prohibit using personal "shelves" for any WIP
  • Instead of using intermediate Test-branch for syncing developers may want to try and use direct cross-branch merges on demand (but anyway see p.2)
Lazy Badger
  • 94,711
  • 9
  • 78
  • 110