We are thrilled to announce the immediate availability of Git hosting across all ProjectHut plans. Git is the world’s most popular Distributed Version Control System (DVCS), and the addition of this powerful tool means that ProjectHut now supports any distributed or centralised version control workflow that your team needs to maximise their development productivity.
Every ProjectHut plan, both new and existing, have been extended to include Git support. The number of Git repositories assigned is the same as the number of Subversion repositories. So for example, a Developer plan with 5 SVN repositories now also includes an additional 5 Git repositories, effectively doubling the total number of repositories, should you wish to use both tools. As usual, our Enterprise plan has no limit to the number of Git repositories. To find out more, checkout our updated Pricing page for a description of the plans available.
So what can you do with Git that you can’t with Subversion? Well the primary difference is that a checked-out copy of a Git repository includes the full history of the repository, rather than just the most recent revision. This makes local commits and merge operations extremely fast, and actively encourages the effortless creation and use of branches.
With Git, your developers can share and work on branch changes together, even independently of the central ProjectHut repository. It allows your team to design a development workflow that best suits your product and your organisation.
As with all the services offered at ProjectHut, security is our number one priority. Our Git repositories can be accessed only via encrypted and authenticated HTTPS network connections. We provide the ability to precisely control access to each Git repository, allowing you to specify exactly which users or groups should be granted access. For projects that require it, there is also the ability to allow public (non-authenticated) read or write access if desired.
To get started with Git now, login to the ProjectHut Control Panel. Regular users will notice a new Git Repositories option in the menu. Here you can create and manage your repositories, assign permissions and edit other repository settings.
In addition to using your favourite Git client, you can also view the status and browse the commit history of each repository using your web-browser. A Gitweb interface is provided at the same URL as each Git repository. For security, this area is also password protected, so only authenticated and appropriately authorised users can access it.
In conclusion, we are extremely excited about this new addition to our service offering. We encourage all users to try it and see for themselves the benefit of utilising a Distributed Version Control System in your workflow. We remind anyone who already has Git repositories that that they wish to import, we are happy to import them free of charge – simply submit a support ticket and we will be happy to help!
For any general tips or suggestions you might have on the service or the updated Control Panel, please take the time to send us feedback. Enjoy!
Have you ever collaborated with other people to work on a project? Did you experience the pain of swapping files to make changes, edits and revisions? Large, fast-changing projects with multiple users need systems that facilitate storage and sharing of files; and track changes in each revision of the file.
A version control system (VCS) is software that facilitates the efficient management of files and directories. Many programmers and designers use VCS nowadays to facilitate tracking of changes in their projects.
Subversion is still the most widely used version control system, which is a more enhanced version of Concurrent Version Systems (CVS), which had had been the number one VCS in the market before other alternatives became more available. Recently, many programmers are starting to use distributed Software Configuration Management (SCM) tools such as Git and Mercurial, that also function as version control systems.
This post reviews some of the top open-source version control systems and tools available today.
Concurrent Versions System (CVS) is one of the oldest VCS in the market. It was developed by Dick Grune as a series of scripts in 1986. CVS is a very simple system that makes sure that all files and revisions are up to date. It still proves useful for designers and software engineers that want to backup and share their files.
CVS has still many clients including Tortoise for CVS on Windows. Also, many integrated development environment (IDE) such as Xcode, Eclipse, and Emacs still support CVS.
Subversion is still the most used version control system, especially in corporate environments. It is distributed as free software under the Apache License. Many open-source projects use Subversion as a repository. This is because other larger open-source projects, such as SourceForge, Apache, Python, Ruby, use it to manage their project development and releases.
What are some benefits of using SVN? Firstly, working copy of files are always writable and all changes done to it are local until it is committed to the repository. There is also an easy access to commit logs that describe the change history, and an ease in reverting unwanted changes. SVN also integrates with almost everything, such as Windows and various websites. And it is known for its ease of setup and administration.
Distributed version control systems offer new functionality over the central repository systems used by CVS/Subversion (SVN). Unlike SVN and CVS, which use centralized version control, distributed SCMs do not necessarily have to have a centralized code or master copy of the software. Imagine if your team is working on a project, and you have a repository on your server. You can clone the entire repository to your laptop, and take it away with you. You can then work at home, on a park, or wherever you wish. Also, distributed version control systems (DVCS) have more functionality to offer, but they are also a little more complicated.
Git was originally created by Linus Torvalds to manage the source code for the Linux Kernel project. It is free software distributed under GNU General Public License. It is the most widely used DVCS and is known to be a fast and efficient system.
Git has many remote hosted repositories, with services like GitHub popular with open-source projects. The distributed nature of Git makes it easy for users to contribute on a large project with minimal centralized coordination. However, Git isn’t as easy to understand for beginners unlike CVS or SVN, and some organisations prefer the centralized control offered by SVN/CVS.
The second most popular distributed version control system is Mercurial. The name “mercurial” means relating to or having characteristics (which include fluency, agility, cleverness) attributed to the god Mercury. The creator and lead developer of Mercurial is Matt Mackall.
It is very similar in many ways to Git, although it is a much simpler system that is why it appeals to some programmers. Mercurial was also designed for large projects, but that doesn’t mean that small programming teams could not use it. It is superbly fast given that the creators made the software with performance as its number one feature.
These are four of the most popular version control systems in the market today. Although there are many others available, these are the VCS that you are most likely to encounter. Choosing Git or Subversion for your next project will ensure your version control system is best understood and supported by your developers.
Have you tried working with Subversion, the tool that saves a history of all revisions of your files? Version control with Subversion enables you to track and manage all the changes in your files, compare different revisions, revert to previous versions, and collaborate with other users while catching and managing any conflicts that may occur.
This post aims to provide some tips for new users on doing version control with Subversion. These tips are general in nature, but also contain some instructions specific to TortoiseSVN.
Subversion is designed to ensure that you don’t lose the changes you make to a file. But what if you DO want to undo those changes? The ‘revert’ command in Subversion that will do exactly. To revert means discarding all changes or modifications that are made to files that are not committed yet, are restore it back to the last known state.
Subversion ensures that you usually delete the right file by asking you with a prompt. If you happen to select the wrong file to revert and accidentally clicked “yes” to the prompt, you can still retrieve the file. TortoiseSVN does not just revert your files, it also moves the file to the Windows recycle bin. So you can find your files in the recycle bin and simply restore them.
Note that using the recycle bin is optional. You can disable the use of recycle bin when reverting by unchecking the option “Use recycle bin when reverting” in the settings dialog of your Subversion.
When doing version control with Subversion, you can move and rename versioned files inside a working copy. If you want to rename a file or folder in place, use the Context Menu, then click Rename. You must enter a new name for the file and you’re done.
If you want to move files around inside your local copy, perhaps into a subfolder, select the files or directories you want to move. Drag them into the new location inside the local copy using the right mouse button. Release the right mouse button. In the popup menu, select Context Menu then choose SVN Move versioned files here.
Important: if you move or rename files without using proper Subversion commands it can lead to errors. For example, if you rename a file named file1.txt to file2.txt without using the Subversion command, file1.txt will appear as missing, while file2.txt will show up as “non versioned” in the commit dialog (Check for Modifications dialog).
You can still correct your files by going to the Check for Modifications dialog or commit dialog. Then you must select the files (Ctrl-click), right click, and choose “Repair move” from the context menu. The “Repair move” command will only work if two files are selected— one “missing” file, and another “non versioned” file. This is the only that way can Subversion find out which file was renamed. By executing the command, Subversion repeats the renaming of the file.
The revision graph shows you a quick overview of your project. However, you cannot share your graph to other people unless you save it as an image. If your graph is small, you can simply save it as .png file. You can also save the graph as .wmf file but note that .wmf files can only open in Windows.
If you are using TortoiseSVN 1.7 or newer, the revision graph can also be saved as a .svg file. A .svg file stores the image in a vectored format and hence it can be resized without affecting its resolution, unlike a .png file that is pixilated when enlarged. It can also be viewed in all modern browsers.
When zipping or archiving files, you may want to remove the hidden .svn folders inside your Subversion working copy. To do that, you can export in Subversion. Exporting a working copy will create a copy of the files without the unwanted .svn folders, however Subversion can no longer track changes in the exported copy.
Right-click on a working copy and choose “Export” from the context menu. A browse dialog of folders is shown where you can choose the folder where you want the new working copy to be exported to. If you select the same path of your working copy (that is, you are exporting a working copy onto itself), then Subversion will remove all hidden .svn folders of that local copy.
It is possible for you to move or copy your files not only with the left mouse button, but also with the right mouse button. What is the difference between the two? Left drag does the command immediately, but the right drag will first show a menu where you can choose the operation.
Subversion provides additional commands in the right drag context menu. When you drag unversioned files using the right mouse button, you will be given a context menu that will enable you to add the files/folders to the working copy. An entry “Apply patch” will also show up if you drag a *.patch or *.diff file onto a working copy. This command opens up Subversion Merge allowing you to apply the patchfile to that working copy location.
Also, if you right drag a file into the location where the file already exists, SVN will ask you if you will rename the file, overwrite it, or cancel the move. Hence, right drag is useful when you simply want to export your working copy to another folder, as well as when you want to reorganize your files by copying and moving them around.
These five beginning tips for version control with Subversion should help you get started today. Make sure to come back for more Subversion tips in the future!