DEV Community

Discussion on: History of Version Control Systems VCS

Collapse
 
elmuerte profile image
Michiel Hendriks • Edited

SVN is also a centralized system, the workflow for a user looks pretty similar to GIT with some term differences, and of course GIT is distributed more on that later. The workflow is something like this, create a branch from the trunk (Trunk is like the master if you are a git user), make changes then merge back to trunk.

That's not a typical workflow for centralized version control systems, and thus not SVN.

In SVN you check out the code (can be any path*), you make your changes, and you check them in. This is generally done with as little branching and merging as possible. Trunk based development is common practice.

*) in an SVN repo you can check out any path you desires. Commonly people organize their repo in:

  • /trunk
  • /branch/*
  • /tags/*

But this is mostly an inheritance of CVS. You can check out /trunk/foo/bar/quux and just work on that. In quite a few cases SVN is used with a monorepo, for example ASF uses a monorepo for all SVN based projects.

Collapse
 
thefern profile image
Fernando B 🚀

Thanks for the correction, trunk development sounds like a lot of pain imho. Is it really that hard to use branches in svn, and merge later on to trunk? What happens if you have 3 people working on different things working straight on the trunk?

Collapse
 
elmuerte profile image
Michiel Hendriks

People working on different branches and changing the same files (in those different branches) is a really really bad thing. And this is something svn only handles with manual merge conflict handling.

Key to successful development with a lot of people on a shared code base is continuous integration. Trunk based development is also an essential part of proper CI.