Check-in before code review is an antipattern

Re:Check-in before code review is an antipattern by SilasX on Saturday January 23, 2016 @09:07PM (#10961139)

Yeah I read it and am still confused: Subversion doesn't let you have branches like git, where it's just some version of the code people can toy around with on their machines without affecting anyone? Any sharing of code to the central repo blocks further work?

If true, that seems like Stone Age code workflow. You might as well argue that code should be tested before deployment rather than edited on production directly, or that it's a really neat idea to keep track of who changed what code when. Duh?

[ Parent | on HN ]

Re:Check-in before code review is an antipattern by klodolph on Saturday January 23, 2016 @10:35PM (#10961348)

Yes. I currently use Subversion at work, and the only way I keep things working smoothly is by using Git locally, and then checking changes from Git into Subversion when they're fully tested (at least developer-tested, not QA-tested). A coworker recently asked permission to branch, and our manager denied the request. The last time my workflow was like this was back in the 1990s, and it certainly feels like the stone age.

[ Parent | on HN ]

Re:Check-in before code review is an antipattern by mooreds on Saturday January 23, 2016 @09:14PM (#10961154)

Subversion does let you have branches, but every shop I have worked in that used subversion used branches rarely, if at all.

The branch-merge default of git is really remarkable, and is baked into the tool and the community.

[ Parent | on HN ]

Re:Check-in before code review is an antipattern by Grue3 on Sunday January 24, 2016 @11:27AM (#10962934)

On the other hand, in one shop where I worked we not only used Subversion branches, but also a modified GitFlow adapted for Subversion. It worked pretty well.

[ Parent | on HN ]