We are pleased to announce the availability of new payment options available for all our customers. Starting from today, customers will have the ability to make invoice payments using their Visa or MasterCard directly, rather than indirectly via a PayPal account.
For the provision of this service we have partnered with PayDollar by AsiaPay Limited, Hong Kong’s largest online payment provider. Customers will notice a slight change in the invoice payment process, whereby they will be redirected to the PayDollar Payment Service to enter their card details. This process ensures that, in the unlikely event of our billing system being compromised, there is no chance that your card details could be lost, since we don’t ever store credit card details in our database.
This new service also supports the Verified By Visa and Mastercard SecureCode third-domain security verification process, for cards that support it. With this system each transaction must be approved by your bank directly, thereby eliminating the possibility of your card details being used without your personal verification.
The other benefit of this change is that we will now have significantly improved ability to diagnose and assist with any payment problems that may arise. This will be welcome news for any customers who may have suffered inexplicable issues with PayPal transactions in the past.
Of course, for customers who still prefer to use PayPal, this option is still available. Just make sure to click the PayPal checkbox on the invoice payment screen.
We are excited to announce the deployment and general availability of a brand new version of the ProjectHut Control Panel!
Existing customers will be familiar with the old Control Panel, located at the admin/ area of their account. This new console replaces and extends the functionality of the previous interface, and can be accessed at the same URL location.
Features of the new Control Panel include:
Although not as visible, behind the scenes there have also been many other technical improvements to the Control Panel. These include: upgrading the Control Panel app to the latest Rails 4 / Ruby 2 platform, refactoring the app to use a RESTful API URL structure, support for turbolinks and asset pipelining for improved performance, as well as improved test coverage.
We have now also fully automated the deployment of the Control Panel application, so we can adopt a more iterative and incremental deployment process in the future. This means we can roll-out new features and fixes more quickly and more often.
We encourage all customers to login to their Control Panel area and try out the new interface. Please let us know if you encounter any issues, and also if you have any suggestions on how we might improve the interface further!
Have you ever tried working on a collaborative project involving multiple contributors without using any special software to manage versions or track changes in files? Just trying to keep track of which file is the latest version of a particular document will be enough to cause many a headache!
Version Control Systems (VCS) on the other hand, are computer software designed specifically to track changes in documents, images, programming codes and other types of files. These tools allow the user to trivially identify the latest version of files, and also retrieve older versions of the files if needed. One of the most popular free version control systems is called Subversion, or SVN for short.
This article provides some basic introductory information that you need to understand in order to do version control with Subversion. Let’s start by defining terminologies.
Versioning is a process where the state of a project is committed or saved at a certain point in time. In software development, versioning is necessary for the improvement of the project while still being able to track the changes from previous revisions. This process also ensures that people are working with the latest revision of the files.
The repository is a database where all the file data is saved. It contains the contents of all the files that comprise the project, together with all their previous revisions. In the repository, anyone can check-out a copy of the files onto their local machine, but only an authenticated author can check-in files.
A revision number is used to track all the files inside the repository. With Subversion, this number is incremented by one every time a new version is saved to the repository.
A working copy is a local copy of a particular version of the files. For example, consider a situation where you wish to work on a file in the repository. First, you have to “checkout” that file from the repository and save the file in your computer as a working copy. You then edit the file and make whatever changes you wish to make. When you have finished editing the working copy, it is then committed back to the repository and is saved with a new revision number.
Committing is the process whereby the local changes made in the working copy is sent back to the repository.
A working copy can also be updated with changes made by other uers. For example, consider a situation where you have checked out some files from the repository. In the meantime, someone else has also checked out one of the same files to make other changes and has since committed it back into the repository. You can then update your working copy to the latest version so it matches the revision in the database. This step is necessary to resolve any conflicts and avoid any problems when you commit the file into the repository.
Merging is a process whereby files from two different versions are combined into one final version. When files are merged, any conflicts that may arise must be resolved by the authors.
Now that you are familiar with some of the terms used in SVN, here is the workflow to manage version control in Subversion.
Thats basically it! This information should hopefully be enough get you started with version control with Subversion. Go and focus on your project, and let the software worry about tracking all the changes to your files!
Version Control Tools enable us to store and share files with other users, track changes in each revision of the file, and compare different versions of our data. Program developers, designers, and even writers today use version control tools to prevent loss of files and facilitate reverting to previous revisions. Nowadays, Subversion (SVN), an improved version of Concurrent Versions Systems (CVS), is the most widely used centralized version control tool. Distributed version control tools, such as Git and Mercurial, also offer a different workflow functionality to the single repository system of Subversion.
This article reviews the usability of some of the top open-source version control tools available today.
Concurrent Versions System (CVS) is one of the oldest version control tools in the market. You may want to use CVS if any of the following is true for you:
CVS has been used for many years and is considered a mature technology. However, as it is now an older software, it lacks some of the functionalities offered by more current version control tools. For example, CVS is not capable of atomic operation support, which may potentially lead to source corruption. Moving or renaming files in CVS also does not include a version update, as it must be performed by manually modifying the repository files. There are also security risks from symbolic links to files, and branch operations of CVS are expensive, as CVS is not designed for long term branching.
Subversion is still the most widely used version control system. It was built initially as an alternative to CVS. It fixes some bugs in the CVS system while maintaining high compatibility with its workflow. SVN is released free as open-source software. Unlike CVS, SVN employs atomic operations which prevent corruption in the database. Either all of the changes made to the files are applied at once, or none of them are applied, so no partial commits can break the original source. Also, SVN offers cheaper branch operations and wide variety of plug-ins for integrated Development Environments (IDEs).
However, SVN still relies on having access to a centralized repository to perform many operations, unlike the peer-to-peer model adopted by some of the new distributed version control systems.
Git was originally written by Linus Torvalds, the creator of Linux. The original concept for Git was to create a version control tool that is faster and based on a distributed system, unlike SVN or CVS. Git is equipped with a variety of tools that help users navigate the history and merge complex changes easily.
Git uses a distributed repository model. Hence, anyone in the team can have their own complete copy of a repository on their machine, and they are free to work offline if required. While this may have its benefits, some organizations prefer the additional centralized control offered by systems such as SVN and CVS. Also, Git is considerably more complex to understand than SVN or CVS and it has historically had limited Windows support compared to its excellent support in Linux.
Mercurial is very similar to Git, however its interface presents a much simpler system, which is is why it appeals to some developers. Developers will notice that Mercurial share some features with SVN. Thus, those who are familiar with SVN as version control tool learns Mercurial quickly. The documentation for Mercurial is also more complete and user-friendly, hence it facilitates the learning process.
So which version control tool should you choose? If you are new to source control, have a small team or if you want a single master source tree, then SVN is the first system you should try. SVN is reliable and is easy to learn. If you are working with a large, distributed team, and you will be working at different times and will be submitting several updates to the code simultaneously, Git is a great choice. Git is fast and has an improved brnach management over centralized systems. If you are somewhere in the middle, or if you find the complexity of Git confusing, you can always try Mercurial.
All of these version control tools are freely available and fully functional (except perhaps for some of the limitations of CVS). So, consider the nature of your project and your team and choose the version control tool that suits your project best!
Source Code Control is the process of using Version Control Software to manage computer program source code and other documents. It functions as a repository that saves your complete project, including all images, codes, files, and directories. It can record the entire history of your project, and allows you to track changes through the different versions of your files. It then enables you to compare your current document to any of its previous versions.
If you are working with a series of files or directories, a source code control system can do several indispensable things for you.
Depending on the type of version control system you choose, there would be a number of limitations you have to deal with. One problem with most source code control software is that changes or modifications could be done to a file without noting why the change was applied. Source code control can’t stop this event, but it does prompt programmers to document changes when they commit them.
Also, when multiple users merge changes on a single file, conflicts may occur if different changes are applied to the same lines of text. Source code control can’t resolve the conflict on its own by choosing the correct modification, however it can identify it. The developers or users need to step in to resolve the conflict.
Source code control is an important tool in large, fast-changing projects with multiple users, or small projects with multiple source files. You may need to use source code control if you are a software developer working on program source code or a graphic artist working on images or illustrations. If you have files documenting various stages of a single file – for example, named logo-old, logo-new, logo-new2, and logo-final – then you might need source code control to simply track the changes to your image or document.
You might also find it useful if you are managing collections of Word documents relating to a project. To save the Word documents, you probably use multiple storage devices for your backups. With source code control software, you can simply use the repository as your backup – not only will you take up less disk space, you can also enjoy the additional revision control tracking abilities of the version control software to boot!
In the book or magazine publishing industry, where many revisions of documents are made, source code control can help in managing the documents while keeping the latest version of the file readily available. Likewise, many web developers also find such systems useful for managing and deploying changes to .html and .css files.
A Version Control System (VCS), also known as a Revision Control System, is software that manages changes to collections of files and directories. While a VCS is useful for managing changes to many types of files, this software is particularly useful for programmers to save files for the source code of computer programs. A VCS keeps track of all of the changes that occur in each revision of the file, the person who made the changes, and the reason behind the modification. Changes are usually identified by an incrementing number (also known as revision number) or letter code, and reflect the content of the files at a specific point in time.
Why is there a need to use a VCS when you can simply save the files in a different filename in one folder? Unlike your usual multiple file saving process, a VCS does not store the full copies of each revision. Instead, it stores only the changes that happen in each revision. That saves a lot of disk space, and also removes the need for the user to manage the naming of the revisions manually. Hence, a VCS is particularly useful for large, fast-changing projects with multiple authors who all need to track and coordinate all changes in each version.
When the most recent version of the file is modified or corrupted, a VCS makes it easy to go back to the previous revision and start again. Also, programmers use the VCS to compare the different versions of their software. By comparing the different versions, they can determine when bugs were introduced and also when were they fixed. Any problems that may arise from a change may be addressed by reviewing the revision, noting who made the change, and the reason behind the change.
Tracking of different versions is also necessary in establishing precedence. Because a VCS keeps track of the person who made changes to the file, it can provide necessary data to solve a dispute regarding ownership of code or ideas.
Version control systems are especially useful for collaborative work. Multiple users can edit the files at one time, without affecting each other’s changes. When they have finished working with a file, they can then decide to merge their versions as one. When two users independently change the same part in a file, they are automatically flagged when the files are merged. Hence, they are still responsible for tracking if the final version is correct.
Version Control Systems can be provided using software installed in-house, or can be accessed via an online version control system provider. Online VCS systems also provide additional functionality, such as bug tracking, archiving, and user management. They are often used for projects that do not have the resources yet to maintain their own server for version control, and also for projects that wish to benefit from the ease of use and additional redundancy provided by an online system.
Concurrent Versioning System (CVS) used to be the most widely used version control system. However, Subversion and Git have long since overtaken it, and are now the most commonly used systems for open source projects. The basic capabilities of these systems in some ways are quite similar to CVS, but they offer much greater functionality.
Some version control systems, like CVS and SVN, have centralized repositories. This works by setting up a single repository which acts as the central store of the system. The repository usually stores information in a hierarchy of files and directories. Check-outs and check-ins of files are done with reference to this central repository. Multiple clients can then connect to the repository and commit changes. Normally, they can only see the latest version of the files. However, they can also review the change history and restore previous versions using VCS tools.
Alternatively, in a distributed VCS like Git or Mercurial, many repositories may be used and no single repository is authoritative. Files can be checked out and checked into any repository. When a file is checked into a different repository, it is integrated as a merge or patch. The responsibility then falls on the users themselves to determine which repository is authoritative.
Ultimately, Version Control Systems have been widely studied and applied in the software engineering community for a long time. These systems are being continually developed and improved to best meet the needs of both small local teams and large distributed teams. A VCS is now considered an essential component of any modern software development process.
We have just finished an extensive overhaul of the ProjectHut Knowledgebase. As a result, we have extended the FAQ by adding an additional 30 new articles covering the most Frequently Asked Questions answered by our support team! The FAQ has also now been categorised into sections to make it easier to locate the answer to your questions.
Should you have any questions about your ProjectHut account, we recommend trying the ProjectHut FAQ first. If you still don’t find an answer to your question there, then of course please submit a support ticket request via the ProjectHut Member Center.
Non-customers are also invited to ask questions by using the Contact Us page on our website.
Many readers may have heard of the phrase “SVN repository”, but may be unsure exactly what it is. Maybe you have a bit of an idea, but don’t know where or why you would need to use one. This post explains in straightforward terms what is a SVN repository, and gives you a basic understanding of how it works and when and why you should use one.
SVN is a shorthand abbreviation of the name “Subversion”. For those who have not heard of it, Subversion is a powerful open-source version control system that is typically used to manage the collections of files that make up software projects. However, a SVN repository it may actually be used for managing any collection of files that are changed or modified over time.
Subversion was initially developed by CollabNet as an alternative to the earlier CVS version control system, which suffered a number of limitations, such as being unable to move or rename files. These days Subversion is actively developed and maintained by the Apache Software Foundation and you can download SVN for most platforms for free.
The SVN moniker itself actually comes from the name of the command that is typed when accessing SVN repositories via the command-line of a computer, hence it is common practice to use the terms ‘svn’ and ‘subversion’ interchangeably.
In simple terms, a SVN repository (or Subversion repository) is a collection of files and directories, bundled together in a special database that also records a complete history of all the changes that have ever been made to these files.
Conceptually, a SVN repository is similar to a folder or directory on your computer that may contain a collection of assorted, but related, files and directories. In fact, a SVN repository is typically used to store all the files and directories that make up a single project, or perhaps even a collection of interrelated projects.
However unlike a normal folder on your computer that stores only the most recent copy of a collection of files, a SVN repository also stores the history of those files.
One way to think of a SVN repository is by imagining a series of snapshots, called revisions, that record copies of all the files and directories that make up a project at specific points in time. However instead of storing full copies of each revision of every file (which would very quickly require a huge amount of disk space!), a SVN repository only records the changes or differences between files at each revision. These differences are known as a changeset.
A SVN changeset consists of a description of all the additions, modifications and deletions to files within the project required to go from one revision to the next, along with a human-friendly text description that reports the nature of the changes. The collection of all changesets in a project is what makes up a SVN repository.
By drawing on this database of changesets, the Subversion tools are able to recreate exactly any revision of any file in the SVN repository, at any point in time. Not only that, it can do so by using far less disk space than would be required if full copies of each of the file revisions were stored instead!
By storing a complete history of every change ever made within a project, it is possible to use a SVN repository to do many things that would be difficult or impossible to do with only copies of the project files alone.
To get started using Subversion, you first need to have a SVN server to host the repository. There are several ways to do this, depending on your technical knowhow and the benefits you wish to achieve by using it. For example, you can:
Whatever solution you choose, once you start using Subversion the power of a SVN repository becomes apparent very quickly. Over time you will discover more and more ways that you can benefit from version control, and eventually you will begin to wonder how you lived without it!
What uses have you found for your SVN repository?
After many months of planning, design and implementation we are proud to unveil the brand new ProjectHut website!
Gone is the old fixed-width website that has served us so well for the past six years – the new ProjectHut website has been completely redesigned from scratch to feature the latest in modern, mobile-ready responsive web design. The new layout will adapt dynamically to best fit the size of your browser, making the site easier to read on all mobile devices, tablets and conventional desktop browsers.
With the new look comes an improved layout and content to make it easier to understand the features and benefits of using ProjectHut for your projects. The Knowledgebase section has been revised and improved, and a completely new Software and Resources section added that contains instructions on where to find Subversion client software or IDE plugins for your Mac, Windows or Linux based development environment. Existing customers will also notice that the ProjectHut Member Center also has a new look with better integration with the main website.
Coinciding with the launch of the new website, we are also excited to announce a set of brand new ProjectHut Plans! All our plans now offer vastly increased storage quotas at significantly lower prices.
For example, our old Developer plan only offered 200MB storage space for $9.95, but the new Developer plan features a massive 1.5GB storage for only a low $9 per month!
In addition, we have also added brand new Corporate (15GB) and Enterprise (45GB) plans that offer much greater storage capacities for customers who have outgrown our previous packages.
Of course, all our plans continue to offer unlimited users and groups. Make sure to check out the new ProjectHut Pricing and Plans page for more details!
We are now offering customers who sign-up to ProjectHut for the first time the opportunity to try ProjectHut free of charge! Yes, for the first time ever, we are waiving charges for the first month’s service. You do not even need to enter any payment details when signing up!
If you have ever considered trying out our service but been unsure about what to expect, then now is the chance to try the full ProjectHut service completely free of charge! There is no obligation to continue beyond the trial period, so should you decide it is not for you at any time simply let us know and we will close the account. Of course, we do very much hope that you will decide to stay, and if so you will only be required to make a payment starting from the second month of service.
So, with nothing to lose and everything to gain, Sign Up Now to start using ProjectHut today!
Following an analysis of customer network usage patterns, we have decided to remove the transfer limits that previously applied to all ProjectHut plans. It turns out that these limits were never even close to being reached by any of our customers, and so in order to simplify the ProjectHut service they have been removed entirely.
Astute customers will have noticed that the “Monthly data transfer” and “Transfer limit reset” fields have been completely removed from the ProjectHut Control Panel. You can now use the service in a way that best suits your project workflow, without ever worrying about the possibility of encountering any limitations!
