Hacker News new | past | comments | ask | show | jobs | submit login

Well, I, for one, am doing per-commit code reviews :) And I think it is working quite well for our team. The feedback loop is very quick.

Not sure what you mean by "codebrag is single-branch", as we do support multiple branches (from 2.0, maybe you tried the previous version?).

Also, SVN promoted a radically different model of working (huge commits, instead of multiple, fine-grained small commits).




Ah, I got the info in re: single branch from the comments on this blog post: http://blog.codebrag.com/post/72667221208/implementing-code-...

From the comment replies it sounded like it can only be on a single branch at a time unless you want to restart the app every time you switched branches. Does each developer run their own instance?

I'd assumed all of that post and the comments were about version 2.0, considering it was linked to from the 2.0 documentation "getting started," you can understand my confusion.

The FAQ only says it supports branches (not a word about multiple branches, unlike previous blog articles that took me a while to dig out) -- it makes it seem like 'sure, you can set up code reviews on a branch!'

The link to the blog from the docs page points to nowhere. I just found it by going back to the beginning.

I was also trying to find version deltas (e.g., what's new about version 2.0 from 1.x?), and I guess some 20 second youtube videos count but... if the code reviews are there, shouldn't there be documentation, too?

I haven't used the product; it looks kind of interesting... if extraordinarily light on the details. It gives me no incentive whatsoever to try it out - the only differentiating factor it has between the github pull request review cycle is the per-commit review (I still can't quite git over this) and the ability to heart a line.

If you have [wip] tags for larger e.g., refactors, how do you keep your single branch in a releasable state for production hotfixes? Does every commit kick off a regression test in jenkins? If a [wip] breaks your tests but leaves it in a releasable state, how do you know? If you did know and you needed to get a hotfix out ASAP for something else, do you revert the commit, or do you rebase to a known-stable tag? That just seems ... dangerous.

It doesn't seem like the most workable flow for a continuously live project. It might work fine for products that you can release a stable version of every couple of months.

"Because every commit gets reviewed" doesn't quite cut it for large codebases, even with small teams. Code reviews don't catch everything.


Hi - thanks for very detailed feedback.

I've just added/fixed/clarified info about support for multiple git branches.

Regarding [wip], refactors and hotfixes - yeah, for larger refactors we create a separate branches, but this is more an exception than a rule.


Word. You're welcome - it looks like an interesting idea for a tool, I just don't have a use for it at the moment :) I'll keep an eye on it. My curiosity is definitely there, if the gamification bit gets fleshed out more (and if you weren't so adamant about no PR reviews ;) ).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: