Collaborative Work with SVN and Git

Exclusive offer: get 50% off this eBook here
Aptana Studio Beginner's Guide

Aptana Studio Beginner's Guide — Save 50%

Develop web applications effectively with the Aptana Studio 3 IDE with this book and ebook.

$26.99    $13.50
by Thomas Deuling | March 2013 | Beginner's Guides Open Source

Collaborative work is an important topic at present. Many large projects are now being developed in a collaborative way. But this was not always easy for the developer. When many developers are working together on large projects, each developer must have a well-known area of work, and each developer must make sure that he doesn't interfere with the work of the other developers.

Without tools such as SVN or Git, large projects like jQuery or Linux Mint could not be possible. The developers of all these projects are distributed all over the world and they often work in different time zones and have different ways of working, but in the end all the parts are merged into one great project in SVN or Git.

So, SVN and Git are a great enrichment for all developers and essential for the fast progress of large web projects.

In this article by Thomas Deuling the author of Aptana Studio Beginner's Guide, we will take a look at how easy it is to work with SVN and Git in Aptana Studio.

(For more resources related to this topic, see here.)

Working with SVN

At first we will take a look at the SVN perspective.The SVN perspective provides a group of views that help us to work with a Subversion server. You can open this perspective by using the Perspective menu in the top-right of the Aptana Studio window.

The important and most frequently used views related to SVN, which we will take a look at, are the SVN Repositories view, the Team | History view, and the SVN | Console view. These views are categorized as the views selection into the SVN and Team folder, as shown in the following screenshot:

 

 

The SVN Repositories view allows you to add new repositories and manage all available repositories. Additionally, you have the option to create new tags or branches of the Repository. These views belong to the SVN views, as shown in the following screenshot:

The History view allows you to get an overview about the project and revisions history. This view is used by SVN and Git projects; for this reason the view is stored in the Team views group. The History view can be opened by the menu under Window | Show View | History. Here you can see all the revisions with their comments and data creation. Furthermore, you can get a view into all revisions of a file and you also have, the ability to compare all revisions. The following screenshot shows the History view:

Within the SVN Console view, you will find the output from all the SVN actions that are executed by Aptana Studio. Therefore, if you have an SVN conflict or something else, you can take a look at this Console view's output and you might locate the problem a bit faster. The SVN Console view was automatically integrated in the Aptana Studio Console, while the SVN plugin was installed. So if you need the SVN Console view, just open the general Console view from Window | Show view | Console. If the Console view is open, just use the View menu to select the Console type, which in this case is the SVN Console entry.

The following screenshot shows the Console view and how you can select SVN Console:

However, before we can start work with SVN, we have to add the related SVN Repository.

Time for action – adding an SVN Repository

  1. Open the SVN perspective by using the Perspective menu in the top-right corner of the Aptana Studio window.

  2. Now, you should see the SVN Repositories view on the left-hand side of the Aptana Studio window. If it does not open automatically, open it by selecting the view from the navigation Window | Show view | SVN Repositories.

  3. In order to add a new SVN Repository, click on the small SVN icon with the plus sign at the top of the SVN Repositories view.

  4. You will now have to enter the address of the Subversion server in the pop up that appears, for example, svn://219.199.99.99/svn_codeSnippets.

  5. After you have clicked on the Finish button, Aptana Studio tries to reach the Subversion server in order to complete the process of adding a new Repository.

  6. If the Subversion server was reached and the SVN Repository is password protected, you will have to enter the access data for reading the SVN data.

  7. If you don't have the required access data available currently, you can abort the process and Aptana Studio will ask you whether you want to keep the location. If you click on NO, the newly added SVN Repository will be deleted, but if you click on YES, the location will remain. This allows you to retrieve the required access data later, enter them, and begin to work with the SVN Repository.

  8. Regardless of whether you keep the location or enter the required access data, the new SVN Repository will be listed in the SVN Repository view.

What just happened?

We have added a new SVN Repository into Aptana Studio. The new Repository is now listed in our SVN Repositories view and we can check this out from there, or create new tags or branches.

Checking out an SVN Repository

After we have seen how to add a new SVN Repository to Aptana Studio, we also want to know how we can check this Repository in order to work with the contained source code.

You can do this, like many other things are done in Aptana Studio, in different ways. We will take a look at how we can do this directly from the SVN Repositories view, because every time we add a new Repository to Aptana Studio, we will also want to check it and use it as a project.

Time for action – checking out an SVN Repository

  1. Open the SVN Repositories view.

  2. Expand the SVN Repository that you wish to check out. We do this because we want to check out the trunk directory from the Repository, not the tags and branches directory.

  3. Now, right-click on the trunk directory and select the Check Out... entry.

  4. Aptana Studio will now read the properties of the SVN Repository directly from the Subversion server. When all the required properties are received, the following window will appear on your screen:

  5. First of all, we select the Check out as a project in the workspace option and enter the name of the new SVN project.

  6. After this, we select the revision that we want to check out. This is usually the head revision. This means that you want to check out the last committed one—called the head revision. But you can check out any revision number you want from the past. If this is so, just deselect the Check out HEAD revision checkbox and enter the number of the revision that you want to check out.

  7. In the last section, we select the Fully recursive option within the Depth drop-down list and uncheck the Ignore externals checkbox, but select the Allow unversioned obstructions checkbox.

  8. After you have selected these settings, click on the Next button.

  9. Finally, you can select the location where the project should be created. Normally, this is the current workspace, but sometimes the location is different from the workspace. Maybe you have a web server installed and want to place the source code directly into the web root, in order to run the web application directly on your local machine.

  10. Finally, whether you select a different location for the project or not, you have to click on the Finish button to finalize the "Check out" into a new project.

What just happened?

We have checked out an SVN Repository from the SVN Repositories view. In addition to that, we have seen how we can also check out the Repository source code into another location other than the workspace. Finally, you should now have a ready SVN project where you can start working.

File states

If you're now changing some lines within a source code file, the Project Explorer view and the App Explorer view change the files' icon, so that you see a small white star on the black background. This means the file has changed since the last commit/update.

There are some more small icons, which give you information about the related files and directories. Let's take a closer look at the Label Decorations tab as shown in the following screenshot:

Now, we will discuss the symbols in the order shown in the previous screenshot:

  • The small rising arrow shows you that the file or directory is an external one.

  • The small yellow cylinder shows you that the file or directory is already under version control.

  • The red X shows you that this file or directory is marked for deletion. The next time you commit your changes, the file will be deleted.

  • The small blue cylinder shows you that the file or directory is switched. These are files or directories that belong to a different working copy other than their local parent directory.

  • The small blue plus symbol shows you that this already versioned file or directory needs to be added to the repository. These could be files or directories you may have renamed or moved to a different directory.

  • The small cornered square shows you that these files have a conflict with the repository.

  • The small white star on the black background shows you that these files or directories have been changed since the last commit.

  • If the file's or directory's icon has no small symbol, it means the file is ignored by the SVN Repository.

  • The small white hook on the black background shows you that this file or directory is locked.

  • The small red stop sign shows you that this file or directory is read-only.

  • The small yellow cylinder shows you that this file or directory is already under version control and unchanged since the last commit.

  • The small question mark shows you that this new file or directory isn't currently under version control.

If you didn't find your icons in this list, or your icons look different, no problem. Just navigate to Window | Preferences and select the Label Decorations entry under Team | SVN within the tree. Here you will find all of the icons which are used.

Committing an SVN Repository

If you have finished extending your web application with some new features, you can now commit these changes so that the changes are stored in the Repository, and other developers can also update their working copies and get the new features.

But how can you simply commit the changed files?

Unlike a Git Repository, SVN allows you to commit changes in a tree from the Repository. By using Git, you can only commit changes in the complete Repository at once. But for now, we want to commit our SVN Repository changes, therefore just follow the steps mentioned in the following Time for action – updating and committing an SVN Repository section.

Time for action – updating and committing an SVN Repository

  1. The first step, before performing a commit, is to perform an update on your working copy. Therefore, we will start by doing this, Aptana Studio reads all new revisions from the Subversion server and merges them with your local working copy. In order to do this update, right-click on your project root and select Team | Update to HEAD.

  2. When your working copy is up to date, navigate to the App Explorer view or the Project Explorer view and right-click on the files or directories that you want to commit, and then select the Commit... entry in the Team option.

  3. If you select a few directories or the whole project, the Commit window lists only those files within the selection that have changed since the last commit. So, you are able to select just the files and directories that you want to commit. Compose the selected files and directories as you need, and enter a comment in the top of the window.

    Why do you have to enter a comment while committing a change?

    Because, by committing the SVN Repository, it automatically saves the date, time, and your username; with this data the revision history stores information about who has changed which file at what time. In addition to that comes the commenting part. The comment should describe what kind of changes were made and what is their purpose.

  4. To finalize the commit, you just have to click on the OK button and the commit process will start.

  5. As described previously, you can see the output from all your SVN processes within the SVN Console view. In the following screenshot you can see the result of our commit process:

What just happened?

We have updated our working copy in order to commit our changes. Now the other developers can update their working copies too and can then work with your extensions.

It should be noted again that it's recommended to perform an update before every commit. You can perform an update in a single file tree node. You don't have to update your whole project every time, a single node can also be committed.

Updating an SVN Repository

Additionally, similar to the SVN check out, you have the option to update your working copy not only to the Head revision, but also to a special revision number. In order to do this, right-click on the project root within the Project Explorer view and select the Update to Head... option or the Update to Version... option under the Team tab. After selecting one of these entries, Aptana Studio determines all the new files and files to be updated, downloads them from the Repository, and merges them with your local working copy.

Now you should have all the source code from your current project. But, how can you identify which parts of a file are new or have been changed?

No problem! Aptana Studio allows you not only to compare two different local files, you can also compare files from different revisions in your Repository. Refer to the following Time for action section to understand how this works:

Aptana Studio Beginner's Guide Develop web applications effectively with the Aptana Studio 3 IDE with this book and ebook.
Published: January 2013
eBook Price: $26.99
Book Price: $44.99
See more
Select your format and quantity:

Time for action – using the SVN history and comparing files

  1. First we will view the SVN history of a single file. You can do this on a whole directory or project also; for now we will do it on a single file, but the procedure is the same. Navigate to your SVN project in the App Explorer or Project Explorer view.

  2. Select the file or directory that you want to inspect, right-click on it and select the Show History entry in the Team tab.

  3. In the SVN History view (as shown in the previous screenshot), at the top you have a list of all the revisions, and the location where the selected file was changed and committed. In our case, the file was initially committed first in revision 8, and updated in revision 25 and 26. Additionally, you can see the date of the revision and the name of the user who had committed it. The last column is the Comment column, where you find more information about what was changed in the commit.

    The list on the bottom area of the SVN History view depends on the selected revision in the top area and shows you which files are affected in the current selected scope of the History view.

  4. If you double-click on a single file in the bottom list, Aptana Studio loads the file in the selected revision from the Subversion server, and opens it in the related editor. In the head of the editor, you can see the number of opened revisions suffixed to the filename as shown in the following screenshot:

    The file opens in read-only mode only because it is an already committed file.

  5. Now you know how to inspect an older version of a file from your SVN project, but it is also interesting to know what parts in the file have changed between the different versions.

    For this purpose, you can use the Compare... function. Select the file you want to compare in the bottom area, right-click on it, and select the Compare... entry.

  6. The window, as shown in the following screenshot, allows you to select the two files that you want to compare. We already selected the first one by right-clicking on it. This file is automatically entered in the Compare from field. The Compare to field is automatically entered by Aptana Studio. Here, Aptana Studio just counts down one number. But, in our case (as shown in the previous screenshot) there is a revision 25. In this case, since there was no revision 25, Aptana Studio selected the revision 8 for comparing, because it was the last checked one since revision 25.

  7. After choosing the two file revisions that you want to compare, just click on OK in order to load the Compare view.

    Switch between the Compare from and to fields

    If the Compare revisions fields have been entered in reverse order, simply click on the Swap From and To button, and Aptana Studio will swap both the fields.

  8. Aptana Studio opens the Compare view of both these file revisions and you can inspect the differences. In our case (in the following screenshot), we compare revision 27 and 26, as you can see from the revision number suffixed to the filenames at the top, revision 27 on the left and revision 26 on the right.

    From the left to the right you can see all the differences. Here it is obvious that only three lines of comments were inserted. You can see a horizontal rule on line 19, which shows a difference. It also ends with a horizontal rule on line 21, where the row with a difference ends. In the space in the middle there is a gray column between both the text areas. In this column visual lines are shown which show the exact line where the new lines were added. In the left row, rows 19 to 21 are connected by a visual line with the right horizontal rule between row 18 and 19. This shows that the new lines were added in line 19.

    A nice feature is, when you scroll the editor towards the left, the right editor will scroll automatically synchronous to the left editor.

  9. But, you don't have to always take the long way via the SVN History view, when you want to compare some files. You can also navigate to the App Explorer view or the Project Explorer view, select the file you want to compare, and right-click on it. In the context menu (as shown in the following screenshot), select the Compare with entry and you will get a submenu with the most frequent comparing options.

If you want to compare two files that are both not in a subversion or maybe even in different projects, just select both of them by holding the Ctrl key within the Project Explorer view, right-click on one of the files, and select the Each other entry in the Compare With option. The Compare view of a compare will look similar to the following screenshot:

What just happened?

We have seen how easy it is to inspect what parts of a file have changed in the previous revisions by using the SVN History view. Starting with listing all available revisions of a file, we also discussed how to compare each of these revisions with each other. Comparing different files that maybe from other projects was also discussed in this section.

Have a go hero – checking out an SVN Repository and working with it

Now, your task is to add an SVN Repository to the Aptana Studio Repository view and then check it out directly into a project. After you have created your SVN project, go forward and work within it. Change some files and commit the changes. When you have committed some files, take a look into the SVN History view and see how the changes are displayed. Finally, choose one file from the SVN History view and compare it with the one from the Head Revision.

Working with Git

Just like SVN, Git is a version control and source code management system, and was initially developed by Linus Torvalds. The difference between SVN and Git is that Git is a distributed version control and SVN is a centralized version control.

Aptana Studio is shipped with a built-in support for Git source control. However, if you are using a Linux-based operating system, you have to install the Git package manually. You can use the following command to do this:

apt-get install git

If you are using a Windows-based operating system, you don't need to install any additional components. Aptana Studio is pre-packaged with portable Git and so you can start using Git with Aptana Studio immediately.

Cloning a Git Repository and creating a new project with this clone can be done in different ways. At this point, we will take a look at the fastest way to do this.

What is happening?

Like the SVN Processes, the Git Processes are also executed on the console. Therefore, there will be some output found after each action, with one small difference; that Git uses the Aptana Studio system console.

Time for action – cloning a remote Git Repository

  1. Navigate to the App Explorer view or the Project Explorer view. Right-click on the background of the view and select the Import... entry from the context menu.

  2. On the window that has opened (as shown in the following screenshot), expand the Git folder. Select the Git Repository as New Project entry and click on Next.

  3. Now we have to determine the URI of the Git Repository that we wish to clone. For this example, we will choose the Less Css project with the following URI:

    https://github.com/cloudhead/less.js.git

  4. Next, select the Destination directory for the project in which the cloned files should be stored.

  5. Finally, you can complete the process by clicking on the Finish button.

What just happened?

We have cloned a Git Repository and created a new Aptana Studio project in the same process, in which the source code is copied. We can now extend this project. The following screenshot shows you the Project Explorer view, where you can find your Git project:

Sometimes, there are some files that should not be added to the Repository. In this instance, you can add these files to an ignore list similar to the SVN. Just select the related file, right-click on it, and select the Add to .gitignore entry under the Team entry. If it is the first file that was added to the ignore list, the Git Repository gets an additional .gitignore file in the same directory as the ignored file of the project.

Creating a Git Repository

Creating a Git Repository is quick and easy to do. Refer to the following Time for action section to find out how to do this.

Aptana Studio Beginner's Guide Develop web applications effectively with the Aptana Studio 3 IDE with this book and ebook.
Published: January 2013
eBook Price: $26.99
Book Price: $44.99
See more
Select your format and quantity:

Time for action – creating a new local Git Repository for a new or existing project

  1. First, create a project if you want to create a local Git Repository for a new project.

  2. Now, navigate to your project within the Project Explorer view, right-click on it, and then select the Share Project... entry in the Team tab.

  3. In the window that opens, as shown in the following screenshot, you have to select the type of repository that you want to use. Select Aptana Git and click on Next.

  4. Configure the new Git repository. Aptana Studio creates the required infrastructure and saves them within the .git directory.

    Select your project entry within the list, click on Create... and that's it. Aptana Studio creates the local repository and deactivates the Create... button, as the project is now a Git repository project.

  5. Finally, you can close the window by clicking on the Finish button.

What just happened?

We have created a new project (just in case the project was previously not available) and integrated these projects into a new Git Repository. Now, let's do a bit of work on managing our source code versions within our new Git repository.

Time for action – working with a new local Git Repository

  1. Navigate to the App Explorer view and create a new file, for example, create one with the name hello.php and write some PHP code in it. Now our Git project and the new file will look like the following screenshot:

  2. The small question mark on the file icon shows you that this new file isn't currently under version control. In order to mark this file for the next commit, right-click on the new file and select the Stage entry. After this, the small question mark should change to a green plus sign.

  3. Now you have created a new file, written some code into it, and marked this file for the next commit.

  4. In order to commit the new file into the local Repository, right-click on the file and select the Commit... entry.

  5. The Commit window, similar to the previous screenshot, comes with four areas. At the top you will find the content from the currently selected file. At the bottom-left, you will find all the unstaged files; this includes all the files that you didn't want to commit. In the bottom-right, you will find all the staged files, also the files that you want to commit. Finally, at the bottom in the middle, you will find an area for a comment for the commit. Fill in a short comment about what you have done in the changed files and click on Commit.

  6. After Git has finished performing the commit, the area on the bottom-right with the staged files will be cleared. Now you can close the window by clicking on the Close button.

  7. Now that we have checked our first file into the Git repository, we can go forward and add some new lines within our file. After that, we can save these changes and take a closer look at the App Explorer view (as shown in the following screenshot). We will see that there is an * symbol included between the file icon and the filename. This shows that this file is "dirty" (this means that this file has changed since the last commit).

  8. After you have extended your web application and you are satisfied with the result, you may want to commit these changes. You can perform this in a similar way. First you have to stage the files that you want to commit and then click on the Commit... button.

    At the top of the commit window (as shown in the following screenshot), where the currently selected committed file is displayed, you can now see what has changed since the last commit.

    Green rows are rows that have been added, and red rows are rows that have been removed.

    The left column where the line numbers are located has been duplicated. The left-hand side line contains the line numbers from the previous committed file, the right-hand side one contains the new line numbers from the current version of the file.

  9. In order to complete the commit process, click on the Commit button and then click on the Close button.

  10. If you have made some changes that you wish to undo, no problem. Right-click on the related file and select the Revert... entry. Now, Aptana Studio will restore the file to the last committed one.

    If the Revert... entry is grayed out, you may have already staged the file you want to revert. Just select the Unstage... entry first and then revert your changes.

What just happened?

We have worked with our local Git Repository project. In short, we have created new files, filled them with code, and committed the first version into the Git Repository. After that, we have extended our files and committed these changes too. Additionally, we have seen what should be done if you want to undo the changes that you've made.

Pulling and pushing Git remote projects

If you've finished working with the extension of your local clone for a project, or if you want to merge your local clone with a remote one in order to get new extensions, you will come to the point where you need to use the Push and Pull functionality.

Firstly, we need to know what Push and Pull functions mean?

A Push function sends all the changes from a local Git Repository to a remote one and merges them on the remote side, whereas a Pull function pulls all the changes from a remote Git Repository and merges them with the local one.

Time for action – pulling and pushing Git remote projects

  1. Navigate to the project that you want to push, within the Project Explorer view.

  2. Ensure that all the files that you want to push are already committed to the local Git Repository, otherwise you might get the message Everything up-to-date.

  3. Right-click on the project root and select the Push... entry in the Team tab.

  4. If an authorization for the remote Git Repository is required, you will see the following window where you can enter your username and password:

  5. After the Push process is complete, logging from the Git Repository within the Console view can be seen, as shown in the following screenshot:

  6. The Pull process is also easy and can be done quickly. Navigate to the project that you want to merge by pulling a remote Git Repository, within the Project Explorer view. Right-click on it and then select Team | Pull....

  7. In the background, Aptana Studio loads the remote Repository and merges it with your local Repository.

    After this process has completed and providing that no conflicts happen, the console shows you a list of all the files that are new or have changed, as shown in the following screenshot:

What just happened?

We have seen how easy it is to push and pull remote Git Repositories. After pulling a remote Repository, all the new and changed files from the remote side were merged with your local Repository. While pushing your local Repository, you merged your local extensions with the remote Repository so that other developers can pull these new features.

Have a go hero – checking out a Git Repository

Now your task is to create your own remote Git Repository (maybe by a service like GitHub or something similar), and clone it within Aptana Studio into a local project. If the project is ready, begin to work within it and create source code files, stage them, and commit the progress in your work.

Summary

By the end of this article, you should be familiar with SVN and Git Repositories. By working with SVN Repositories you should know, in detail, how to add a new Repository and, how to check out the Repository into a project. After adding and checking out, you should know how to work with the SVN project. This means that you have to know how to commit your local changes, update your local working copy, and know how to use the SVN history for your work.

While working with Git, you have not only seen how to clone a remote Git Repository and work with it within a local project, but also how to create your own local Git Repository. Within your local Git Repository, we had a look at the commit process and how to stage, unstage, and revert files. Finally, we had a look at how to push and pull a Git Repository.

Resources for Article :


Further resources on this subject:


About the Author :


Thomas Deuling

Thomas Deuling is a web applications developer with over 5 years experience in developing large web applications with open source technologies. He started by programming small web applications and websites for different agencies. Currently, he is self employed and has just founded his own company called coding.ms (www.coding.ms). He has managed many large web projects in the past, even developing a whole ERP/CRM system for a large international company. In short, Thomas lives web development.

He is also the author of a German book, Warenwirtschaft und Webapplikationen auf Basis von OpenLaszlo, VDM Publishing, which deals with enterprise resource planning and web applications based on OpenLaszlo.

Books From Packt


Ruby on Rails Enterprise Application Development: Plan, Program, Extend
Ruby on Rails Enterprise Application Development: Plan, Program, Extend

Aptana RadRails: An IDE for Rails Development
Aptana RadRails: An IDE for Rails Development

NetBeans IDE 7 Cookbook
NetBeans IDE 7 Cookbook

NetBeans Platform 6.9 Developer's Guide
NetBeans Platform 6.9 Developer's Guide

Java EE 6 Development with NetBeans 7
Java EE 6 Development with NetBeans 7

PHP Application Development with NetBeans: Beginner's Guide
PHP Application Development with NetBeans: Beginner's Guide

Oracle Fusion Middleware Patterns
Oracle Fusion Middleware Patterns

Instant NetBeans IDE How-to [Instant]
Instant NetBeans IDE How-to [Instant]


No votes yet

Post new comment

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
2
6
h
C
M
k
Enter the code without spaces and pay attention to upper/lower case.
Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software