neandrake

Has there been a recent update with Codebrag? I try to keep an eye on the available code review tools and this one was last updated a while back. The last release/commit/tweet was last June.

The database might have tables for commit data so history etc. can be searched, and possibly used for managing on-server operations like merges etc.

Paul Hammant? Thank you for your blogs and thanks for putting this site together, they're very informative. I work at a company that has been doing "Cascade" model for close to a decade [0], very similar to TBD but not quite the same. In addition to having a mainline trunk repo which everyone's work is pushed to, we have started utilizing Phabricator in the past few years -- it enables us to have short-running feature branches which aren't public to the upstream repository but can be shared if necessary and used for review (I'm not sure how similar this might be to GitHub flow? We use Mercurial).

[0] http://paulhammant.com/2013/12/04/what_is_your_branching_mod...

Rather than a demo, we often ask for screenshots or gifs, which has had similar effect of catching some things earlier.

If you look through the task description on the phabricator task I linked, there is Paste file which has the contents of an extension to allow continued use of graphviz, however they state it's insecure and not supported.

Phabricator had allowed for specifying dot notation in their markdown (remarkup) which would use graphviz to render the images in the comment. I loved this feature but it was removed due to potential exploits [0]. Is anyone familiar with how graphiviz-as-a-service could be possible while addressing these concerns?

[0] https://hackerone.com/reports/88395, https://secure.phabricator.com/T9408

I am a pretty active observer of rust community as the language abilities and paradigms excite and suit me. Therefore I do see steveklabnik as well as several others frequent these avenues. In all my time reading Reddit/HN/etc. I've never seen steve or the others "advocate"; they're doing exactly what that description states which is explain and clarify. The tech community brings up rust as a discussion topic and they spend their own time (possibly some of Mozilla's) to make sure that the community understands the organization (not just Mozilla), drive, and tech behind rust.

It generally refers to something that ruins a happy/good situation -- like throwing a cold wet blanket on someone out on a summer day.

I've not seen it mentioned here (unless included under generic "safety"), but prevention of data races in concurrent code seems like a big thing for Rust. Most examples of Rust being "safe" compared to C are usually about buffer overflows use-after-free, but elimination of data races to me seems like a huge win in its own right. I'm primarily a Java developer and a lot of the practices I'm learning from Rust apply to how I think about implementations in regular work, such as aliasing and mutability.

I've seen several of your comments indicate "requiring naive implementation". This seems strange to me. Why require a naive implementation and then be concerned over some slight differences in performance?

I just recently discovered `hg ci -i` which is a TUI for selecting which changes/hunks to include in the commit. I think it used to be a separate extension but now is part of the main hg distribution. I've tried to use it more now for scenarios where I happened to make multiple modifications to a file while working on a fix/feature and want them in separate commits.

We've been using Phabricator for a few years and have been really happy with it. Initially we brought it on board to help with code reviews (which it is fantastic at), but have since also used it to help manage projects being collaboratively worked on with external customers. I usually jump at every chance to talk about it with others who are interested in learning more.

Definitely check it out if you're looking for hosted or self-hosted alternatives to GitHub/GitLab/BitBucket, especially if you use Mercurial (or SVN).

There's an entire paragraph on that page about it

>This isn’t a scaled-back version of Phabricator. We only build one version, and that version is free, open, and built to scale. There are no special keys or licenses needed. No community or enterprise versions. Code quality and engineering efficiency is too important to us to split up features. When you’re ready to move off of the free tier and bring your whole company, you’re welcome to upgrade on Phacility, or take your data with you and host it locally. We’re glad to have you as a customer either way.

We considered switching to Git as well for a similar reason (GitLab). However we discovered Phabricator provides similar toolset at GitLab and also supports Mercurial. It's open source - you can run a local instance (no cost but also no support) or pay for them to host. They also recently started a free plan where they will host an instance with up to 5 users.

https://www.phacility.com/phabricator/

We've been using it for 2+ years at this point and glad we stuck with Mercurial.

Paul Hammant has some interesting blogs about the topic and he has been talking and promoting Trunk Based Development for a while. We use a variation of it at work, though we have several teams of ~5 working on the same repository.

http://paulhammant.com/2013/04/05/what-is-trunk-based-develo...

http://paulhammant.com/2014/09/29/shades-of-trunk-based-deve...

http://paulhammant.com/2013/12/04/what_is_your_branching_mod...

People are trying to change that. http://letdoctorsbedoctors.com/ - the "EMR State of Mind" parody is pretty fun

Even if that were the case I would think learning powerful tools over the span of a few weeks would be worth the effort if you had the reliability that these tools would exist for years to come.

It seems like the rapid change and throw-away-ability of the tool ecosystem reflects the final product as well -- and maybe that's the large difference which is emergent from web technology? What is the average lifespan of a web application?

As an outsider my question would be why can't the existing tools update and adopt instead of being replaced?

Phabricator also supports hosting mercurial but there are some rough edges. Its need to do some basic monitoring of the wire protocol (primarily to determine whether actions are read/write for ACL and cluster resolving) have uncovered that interpreting the underlying wire protocol is difficult and challenging [0]. I wonder if Kiln or others have similar issues? I would guess that this sort of problem is one of the reasons hosted tooling around hg falls behind git even though touting a great extension API (aside from the large gap in user base).

[0] https://secure.phabricator.com/T9548

I'm not a large JS developer but with my other experiences managing dependencies, it doesn't always allow this as a possibility. A bug in your system is tracked down to the library b using x@1.0 but the fix is to upgrade to b with x@2.0 however a using x@1.0 doesn't have an upgrade path. Waiting for another company or organization to release with an update is not an option. Our projects have several cases of requiring different versions of the same library -- we try to avoid this using the same logic you suggest but it's not a possibility in all cases so we have to work with it.

It's placing your own release cycle at the whims of your dependencies' release cycles. In the corporate world that would not be a viable solution.

>The trick is to have a way for developers to power down somewhat. I'm not sure how you would do that. I never got the chance to figure it out.

When it's time to change pace one of the things I think helps "power down" is to let team members work on things they are interested in or find important. Instead of priorities coming from up high it lets their minds breathe and explore something on their own. The difficulty is in managing to find the time for it.

Won't the performance of version control software largely depend on the size of project history and not necessarily LoC? I work on a project where we just surpassed 100k commits in Mercurial, which includes largefile assets. Cloning is a lengthy process - other operations are also slow such as push/pull/stat and occasionally rebase.

Where I work the same situation often comes up -- a developer may spend weeks doing research for a specialized function building prototypes, etc.

Ensure the specialized developer is doing due-diligence in defining and verifying the module works as intended and have others analyze its interactions in the larger system to prevent cascading failure, conforms to application norms, __is documented__, etc. Even if most others wouldn't understand the internals during review you will be taking steps to keep the risk localized. If the bus arrives and you lose the specialized developer then it's reasonable to assume another developer would need to spend nearly as much time to catch up on the research.

Otherwise you're responsible for making the decision to invest more developer time now in understanding the problem/implementation vs. later - a gamble at how much time until that developer leaves.

Taking over specialized/legacy code is part of the job. It can be painful but there are steps you can take to minimize that pain later.

The only way I'm familiar with instructing mercurial to do this is with

    hg addremove -s

Is there another way to indicate a rename?

You should also factor in their software model. GitLab has a free install anyone can run locally without having to register. A competitor like GitHub has enterprise install but otherwise most public traffic is on their own hosted install. If there's a security issue they likely fix their hosted install and inform their enterprise customers only -- as well they probably shouldn't make it public otherwise it could be considered some level of exposure to their customers. Conversely GitLab essentially needs to publicize this to maintain the trust of their customers.

I believe Phabricator supports this workflow. Create a revision for a code change - as more commits are made, update the revision with those changes. Users can see what changes were made between commits and hold discussions on them. When it's ready, landing can (optionally) squash the diffs into a single commit upstream. The main history will be linear and more-complete changes, while detail about the development of the change is retained in Phabricator revision.

https://phacility.com/phabricator/differential/

If you're still open for suggestions/alternatives, have a look at Phabricator. August-December of 2014 I looked at several different solutions for my company (though primarily my focus was on code review features - today we also use it in some areas for task management and documentation/wiki). I nearly moved forward with GitLab before (re)discovering Phabricator. I like to keep up to date with new features in the alternatives (GitLab, GitBucket, Gogs, Reviewboard, etc.) but at this point I can't imagine wanting to move off Phab.

Homepage, http://phabricator.org/

Their self-hosted install (browse but they prefer that you don't create/test data on this install), https://secure.phabricator.com/

They have paid hosting as well, http://phacility.com/

I started looking into GitLab and Phabricator around August/September 2014 for my company. My criteria was primarily based around something to assist with code review. Ultimately I went with Phabricator for several reasons:

1. Supports Mercurial - our repositories are currently in mercurial, and using any other tool would require switching to git (which we seriously considered while looking at tools).

2. Simple to maintain - if you have experience setting up other web applications based around LAMP, this is essentially very similar. The web interface even indicates setup issues to admins, from things which can cause issues to performance configurations in things such as MySQL and PHP.

3. The code review interface was more intuitive for myself and other engineers. From the command-line tool (Arcanist) to how it's conveyed to the user in the web interface. It did take a little time to fully comprehend and implement the process for using, but since implementing in Feb. of last year, after around 4 months we had near 100% adoption by the engineering department. The GitLab/GitHub interfaces I've found to not be organized intuitively -- the lifetime of an issue/changes seems (seemed?) more social-based and intermized where in Phabricator an Issue/Task is almost separate from the changes which can go into it, though they reference eachother easily.

>Also, do they pride themselves for writing this in PHP? I consider this an anti-feature, but this might be highly opinionated.

I had the same reaction at first (thought I wouldn't say it's pride?). In fact the first time I looked at Phabricator (~2012) I totally dismissed it for three reasons:

1. Written in PHP

2. Mentions pokemon on the front page

3. Marketed as "collection of open source web applications"

These led me to believe that it was at most some PHP glue some students hacked together to get different unrelated applications to play together. This conclusion is entirely wrong. I've since changed my mind about PHP - biased from earlier experiences there's no reason to think a reliable/stable application couldn't be built on it. Phabricator (I believe) started as an internal application at Facebook which has since become its own company. The code is very well organized (I've contributed some small changes), and there are some very bright people working on the project - I get the vibe that they genuinely want to solve the right problems rather than checking features off a list. There are very few dependencies on other libraries unless you specifically decide to enable extra features, and even then there's some support/documentation there to assist. Despite the light-hearted humor (see pokemon) that is a staple of the software (unless you enabled serious-business mode), the project is designed and developed by highly capable, quality professionals.

I couldn't have been happier going with Phabricator over GitLab.

Another shoutout here to phabricator. I started hosting it internally at the company a year ago and have near 100% adoption from developers for code reviews, additionally using the task/issue tracking for some projects.

You have to be a coder to participate~