Dear Tabnine and Codota users.
I’m excited to announce that Codota has acquired Tabnine late in 2019. In this post, I’d like to share more about Tabnine and Codota’s future.
Both Codota’s and Tabnine’s mission is to make developers more productive by automating mundane and repetitive parts of programming. With this shared mission in mind, both Codota and Tabnine set out to introduce AI to software development, using slightly different technical approaches. Each of the approaches has its own advantages and has gained popularity in different communities, which made the decision to join forces straightforward.
I would like to take a step forward and share our plans for Tabnine within Codota.
Tabnine Maintenance: Following the deal, Tabnine’s creator, Jacob Jackson, is now a part of the Codota team as an advisor. After going through intensive in-person training with Jacob, Codota’s engineers are maintaining Tabnine and working with the community to make sure Tabnine keeps improving. Those who follow Tabnine closely might have noticed them getting up to speed in handling issues in the last few weeks. I am confident that with the additional muscle and resources we devote to Tabnine, the project will keep thriving.
Tabnine community: We will continue to work with the Tabnine community to hear feedback, prioritize issues and help the creation of additional plugins for Tabnine. The central GitHub repo will continue to serve as the go-to place for users.
Privacy: We will continue to respect the privacy of Codota and Tabnine users. Both Codota and Tabnine products use the minimal required information for contextualizing queries (over an encrypted connection). This contextual information is ephemeral and is not stored anywhere after the query has been fulfilled. We will continue to clearly communicate what private info is being sent, and how it is used. Tabnine will continue to have an offline mode that does not require an Internet connection and does not send any data to the cloud service.
Product Integration: We see great opportunity in combining the semantic models of Codota with the textual models of Tabnine. Each of them beautifully complements the others, and a thoughtful combination of the two is far superior to any of the models individually. We have recently shipped a beta of the Codota plugin for WebStorm/IntelliJ IDEA that provides code completion based on a combination of the two models. You are most welcome to try it and tell us what you think. Further in the future, we plan to combine the brands so we offer a single product.
Free and paid plans: Both Codota and Tabnine will continue to have free-forever plans that allow developers to enjoy a great code prediction experience. As both Tabnine and Codota originally intended, we will offer paid plans that enable code prediction for larger projects and other advanced features. We are excited to release them soon and believe they provide excellent value to individuals and teams who create software professionally. We will soon start offering student discounts as well.
From day one, Codota set itself to change how we all write code. Leveraging years of research and specialized AI models, we are shaping the future of software development – making developers faster and better. By joining forces with Tabnine, we are now proud to be the market leader in this space.
In sum, we see a bright future for the integration of Tabnine and Codota and see a very promising future for AI-assisted software development. Our success depends on your trust and enthusiasm. We will do everything in our power to be a worthy part of your coding workflow.
Dror Weiss, CEO
Codota
There are plenty of ways to start a fight in a bar full of passionate inebriated devs. One of the more effective methods is yelling out “How can you say SVN is better than Git?” (or vice versa) at a random dev in the crowd. Then sit back and watch mayhem ensue and put your money on the winner (if you’re the betting kind).
In reality, both SVN (Apache Subversion) and Git are effective and popular version control systems (VCS) that enable workflow and project management in software development. There are differences in both the overall approach and industry-recommended best practices. It’s up to each programmer (or development team leader) to pick the right versioning system for every project they work on. Believe it or not, but making the wrong decision can cost developers many hours of work, sweat and tears.
What is the difference, really? When should you pick which? Let’s start with reviewing the distinctions between Git and SVN.
The main and perhaps best-known difference is in its core architecture. Git version control is distributed while SVN is centralized. However, that’s just the tip of the iceberg. Other variations in approach and functionality between the two are important to understand if you want to use either effectively.
| Git | SVN | |
| Server architecture | Installed locally and acts as both server and client. | Requires a centralized server and user client. |
| Revisioning | Git is an SCM (source code management) tool. As such, it does not have a global revision number feature. | SVN is a revision control system. As such, it features a global revision number. |
| Repository cloning | Yes | No |
| Storage format | Metadata | Files |
| Storage requirements | Limited capacity to handle large binary files. | Can handle large binary files in addition to code. |
| Branching | Branches are references to a certain commit. They can be created, deleted, and changed at any time without affecting other commits. | Branches are created as directories inside a repository and when the branch is ready, it is committed back to the trunk. |
| Access control & permissions | Assumes all contributors have the same permissions to the entire codebase. | Allows for granular permissions with read and write access controls per file level and per directory level. |
| Ease of use | Harder to learn | Easier to learn |
| Cryptographic hashing | To protect from repository corruption (due to network issues or disk failures) Git supports cryptographically hashed contents. | n/a |
| License | GNU (General public license) | Open source under the Apache License |
| Change tracking | Repository level | File level |
| Original developer | Linus Torvalds (developed for Linux kernel code control) | CollabNet, Inc |
Based on this comparison, we can pinpoint the advantages and disadvantages of each.
The general sentiment on the web leans toward Git as their go-to solution for version control in their projects. However, several noteworthy open source projects still opt for Subversion over Git (the WordPress codebase) with roughly 24% of projects on OpenHub using SVN. This is precisely the reason we picked to focus on the advantage of SVN over Git first.
One thing that can be said in favor of centralized version control architecture like SVN is that it is efficient in handling network traffic and assuring synchronization between teams and developers.
When you work with SVN you only need to synchronize the differences between what you have locally and the latest on the server. This is much faster than with Git. Due to it being distributed, you have to download all changes, even if those changes add gigabytes of useless assets that have since been deleted from the branch.
This is wasteful, especially if you’re working on a crowded network and don’t feel like taking a nap while the repository syncs. More so if upon waking up you realize you downloaded gigabytes of a repository where the branch you checked out wasn’t even touched by anyone else.
Perhaps the most inarguable advantage SVN has over Git is in how it handles binary files. The reason for this superiority is the support Subversion provides for the Lock-Modify-Unlock model. It is implemented in SVN using a lock command (svn:needs-lock property) while Git offers no exclusive file locking at all due to its distributed nature.
For enterprise projects with multiple non-mergeable binary assets in the codebase, this is a real deal-breaker and often the reason they choose to stick with SVN.
This can be a topic for arguments, but many developers insist SVN is easier to learn and use than Git. Features are faster to add and the syntax is a lot cleaner by offering better abstraction capabilities.
The Git architecture assumes that everyone using it has the same permissions. Getting read and write access to the entire codebase in their own branch is matter of fact. In fact, it has no user permission designation of its own. While fully acceptable in the open source world, this approach can prove risky in an enterprise setting. In many cases confidential and proprietary information might be revealed to third-party contractors working on some portion of the code as a result of bad access control.
Not so with SVN, where granular path-based user permissions are built into the system allowing for tighter code security and control.
Some claim the main reason Git has become the default choice for many developers is actually GitHub and the ease with which it allows for the sharing of code. That in itself is not a reason to pick Git over SVN, but may shed light on why so many do.
A kind of chicken and egg dilemma concerning the superiority of Git unfolds. Is it really better or simply has better PR thanks to GitHub and the open source movement? Either way, it seems that all the cool kids are doing it and even the non-cool kids are catching up.
(Pretty much every dev on reddit ever)
Merging repositories is never easy, no matter what versioning architecture you use. That said, Git is a better architecture for merging repositories. This is simply because the ability to merge code from multiple contributors is the main focus of Git and the architecture was built to enable community collaboration.
Imagine you’re on the road and a critical bug needs fixing. You sync your repository, code the fix while on a flight or at a conference and quickly push and commit. All good so far, but what happens if you find yourself offline? The distributed nature of Git ensures that code can be pushed and committed locally and independently of the main repository. This makes Git versioning not only lighter on network traffic, but also ensures independence from a centralized server which may or may not crash exactly when you need it.
There’s no argument that software versioning is important, and the main debate is over which architecture and approach is best and when.
With Git serving as a decentralized solution aimed at open source development and SVN still a favorite with enterprises, the debate is likely to continue for years to come. Odds are it will just become more vocal with representatives of systems like Mercurial, Bazaar as well as old players (CVS) and new (Microsoft Azure DevOps).
