4 ms·

..and the circle is complete. If you're a fan of this workflow then I can recommend using Visual Source Safe. It even has exclusive locks which completely elim

..and the circle is complete. If you're a fan of this workflow then I can recommend using Visual Source Safe. It even has exclusive locks which completely eliminate merge conflicts. I've been building software professionally for almost 20 years, I've seen (and experimented) with almost every VCS/SCM strategy imaginable. My conclusions: This only really works for tiny teams - 2-3 people who work very well together. It needs high bandwidth communication. For teams of 3-10 short lived feature branches are effective with a little bit of planning to minimize merge conflicts. For larger teams you really have to split the system into self-contained modules or microservices, each module having clear owner. These modules are then shared as source, library or service depending on the actual needs. I've never had good experiences with longly lived branches. They can work whilst adding experimental modules which require only a couple of tiny API changes to the main system; but then splitting the module into a separate project/repository and making the API changes (behind an #IFDEF) makes more sense.

LoSboccacc 11y ago
same here. the only long lived branch we have is the deployed code branch, which I found more convenient than just a tag it also matter average team skill. if you have to make do with what you find/can afford, then feature branches are good at isolating devs from each other non working commits.
koonsolo 11y ago
Sorry, but your experience of Visual Source Safe is totally different than mine. I started working at a small company in 2002, where they used Visual Source Safe. Next to the VSS database file getting corrupted every few weeks, the 3 developers were always asking each other to unlock a certain file because someone needed to make a change in the same source file (but completely different method/location). I introduced Subversion. No more corrupt files (shiver), it just kept on running. And you could actually work on any file. If you divide your work properly, you can work in the same file without working in the same code. And if the small chance of changing the same line occurs, the merge wasn't that complex to fix. We never looked back, and therefore I am completely disgusted that someone actually suggests using such an unstable, non-efficient tool.
- logiclabs 11y ago
  I suspect there might have been a touch of sarcasm in that VSS remark
  - radicalbyte 11y ago
    Yes, I was being sarcastic. Sorry for confusing you koonsolo. Visual Source Safe is an absolute pig, unless you're already using it and can't switch then I strongly advise getting as far away as possible. Team Foundation Server - the replacement - has historically been just as poor. It does however have the advantage of including some extremely powerful software lifecycle management features. Recent developments - such as the Git-based Team Foundation Online - are really rather good, especially if you need more advanced features and like giving Microsoft money ;)
    - mkozlows 11y ago
      I agree with the VSS-hate, of course, but it's unfair to say that TFS is just as bad. TFS is annoyingly difficult to administer, but it's a zillion times more robust than VSS, and compares favorably to Subversion or Perforce (and has excellent Visual Studio integration). Git totally kills it, of course, but as traditional old-school VCS goes, it's not bad at all.
pavel_lishin 11y ago
> It even has exclusive locks which completely eliminate merge conflicts. I assume those locks can be overwritten by an admin, right? I'm exactly the sort of forgetful jerk who'll lock an important config file before going on a two-week vacation.
zeendo 11y ago
In my experience, if you have high bandwidth communication (e.g. a team room) then trunk based development scales to well beyond 2-3 people. I've seen it work on at least one large distributed teams (3 team rooms, 3 time zones, ~30 developers)..and it regularly works on teams of 6-10 developers. Regarding VSS and exclusive locks. No. Trunk based development with no exclusive locks is fine. Pessimistic locking was unwarranted pessimism when applied to source control. Also, note that Google is trunk based...with a single trunk across the whole company. I think Facebook is too?
- radicalbyte 11y ago
  In that case you were absolutely having merge conflicts - only you were forced to resolve them the second you updated your local working copy. Over the years I've lost so much time to small errors resolving merges - particularly the type which involved cross-file refactoring (where two people have moved methods and then refactored them). The beauty of using branches - especially with Git - is that you as developer gain a lot of power over how you apply merges. The "pre" state is also under version control, so you can always go back. Plus if you're using Git then you're implicitly doing branch-based development (git clone creates a local branch). My current team of 6 developers switched from TFS trunk-based to Git with short-lived feature branches and they've not looked back. We've greatly reduced merge issues and downtime caused by bad check-ins. Both still happen, only less than before.
  - zeendo 11y ago
    Of course we still have merge conflicts. You do too. Or is your work just organized such that no two people are ever working on the same file concurrently? If it is then you'd not have any merge conflicts with trunk based development either. Fundamentally merge conflicts are unavoidable. The claim by the trunk based development crowd is that smaller, but more frequent merge conflicts produce fewer mistakes. Trunk based development leads to smaller merges because you do them more frequently. That's about it.
    - spinningarrow 11y ago
OldSchoolPro 11y ago
And still somehow feature switching works great at Facebook, Google and Goldman Sachs with big teams. Merging complex changesets across branches is impossible to do 100% correct every time. Not unless you're a 10 feat tall code crunching robot.

LoSboccacc 11y ago

same here. the only long lived branch we have is the deployed code branch, which I found more convenient than just a tag it also matter average team skill. if you have to make do with what you find/can afford, then feature branches are good at isolating devs from each other non working commits.

koonsolo 11y ago

Sorry, but your experience of Visual Source Safe is totally different than mine. I started working at a small company in 2002, where they used Visual Source Safe. Next to the VSS database file getting corrupted every few weeks, the 3 developers were always asking each other to unlock a certain file because someone needed to make a change in the same source file (but completely different method/location). I introduced Subversion. No more corrupt files (shiver), it just kept on running. And you could actually work on any file. If you divide your work properly, you can work in the same file without working in the same code. And if the small chance of changing the same line occurs, the merge wasn't that complex to fix. We never looked back, and therefore I am completely disgusted that someone actually suggests using such an unstable, non-efficient tool.

logiclabs 11y ago
I suspect there might have been a touch of sarcasm in that VSS remark
- radicalbyte 11y ago
  Yes, I was being sarcastic. Sorry for confusing you koonsolo. Visual Source Safe is an absolute pig, unless you're already using it and can't switch then I strongly advise getting as far away as possible. Team Foundation Server - the replacement - has historically been just as poor. It does however have the advantage of including some extremely powerful software lifecycle management features. Recent developments - such as the Git-based Team Foundation Online - are really rather good, especially if you need more advanced features and like giving Microsoft money ;)
  - mkozlows 11y ago
    I agree with the VSS-hate, of course, but it's unfair to say that TFS is just as bad. TFS is annoyingly difficult to administer, but it's a zillion times more robust than VSS, and compares favorably to Subversion or Perforce (and has excellent Visual Studio integration). Git totally kills it, of course, but as traditional old-school VCS goes, it's not bad at all.

pavel_lishin 11y ago

> It even has exclusive locks which completely eliminate merge conflicts. I assume those locks can be overwritten by an admin, right? I'm exactly the sort of forgetful jerk who'll lock an important config file before going on a two-week vacation.

zeendo 11y ago

In my experience, if you have high bandwidth communication (e.g. a team room) then trunk based development scales to well beyond 2-3 people. I've seen it work on at least one large distributed teams (3 team rooms, 3 time zones, ~30 developers)..and it regularly works on teams of 6-10 developers. Regarding VSS and exclusive locks. No. Trunk based development with no exclusive locks is fine. Pessimistic locking was unwarranted pessimism when applied to source control. Also, note that Google is trunk based...with a single trunk across the whole company. I think Facebook is too?

radicalbyte 11y ago
In that case you were absolutely having merge conflicts - only you were forced to resolve them the second you updated your local working copy. Over the years I've lost so much time to small errors resolving merges - particularly the type which involved cross-file refactoring (where two people have moved methods and then refactored them). The beauty of using branches - especially with Git - is that you as developer gain a lot of power over how you apply merges. The "pre" state is also under version control, so you can always go back. Plus if you're using Git then you're implicitly doing branch-based development (git clone creates a local branch). My current team of 6 developers switched from TFS trunk-based to Git with short-lived feature branches and they've not looked back. We've greatly reduced merge issues and downtime caused by bad check-ins. Both still happen, only less than before.
- zeendo 11y ago
  Of course we still have merge conflicts. You do too. Or is your work just organized such that no two people are ever working on the same file concurrently? If it is then you'd not have any merge conflicts with trunk based development either. Fundamentally merge conflicts are unavoidable. The claim by the trunk based development crowd is that smaller, but more frequent merge conflicts produce fewer mistakes. Trunk based development leads to smaller merges because you do them more frequently. That's about it.
  - spinningarrow 11y ago

OldSchoolPro 11y ago

And still somehow feature switching works great at Facebook, Google and Goldman Sachs with big teams. Merging complex changesets across branches is impossible to do 100% correct every time. Not unless you're a 10 feat tall code crunching robot.