Comparison of Subversion clients

There are several subversion clients as TortoiseSVN, SmartSVN, RabbitVCS, VisualSVN, AnkhSVN, etc... Choose the better svn client is not easy because it depends from the usage you want to do and the other softwares related.
The goal of this short article is to make a brief overview of some of the clients in circulation highlighting the relevant terms for each of them. 

TortoiseSVN

TortoiseSVN implements a Windows shell extension (linux version is not available), it is easy to use, since it doesn't require the Subversion command line client to run. About the license It is a free tool (GPL).
TortoiseSVN's official web page: https://tortoisesvn.net/

SmartSVN

SmartSVN is a client avaible for OS X, Linux and Windows. It provides a good user interface. About the license, there are two versions: free Foundation edition and as full-featured Professional edition. 

SmartSVN's official web page: http://www.smartsvn.com/

RabbitVCS

RabbitVCS is a set of graphical tools for linux written to provide simple and straightforward access to the version control systems you use. It is not only svn client but even for others source version controls, for example Git. About the licence, it is an other free tool (GPL). You can see some screenshoot in this page.
RabbitVCS's official web page: http://rabbitvcs.org/

VisualSVN

VisualSVN is a professional grade svn integration plug-in for Visual Studio. I think that this plug-in is mandatory if you use svn and Visual Studio.  About the licence, there are more versions also free versions, all details are described in this page. You can see some screenshoot in this page.
VisualSVN's official web page: https://www.visualsvn.com/visualsvn/

AnkhSVN

AnkhSVN is an other Subversion Source Control Provider for Microsoft Visual Studio 2005-2015 and 2017.  About the licence, it is an other free tool but with Apache Licence. You can see some screenshoot in this page.
AnkhSVN's official web page: https://ankhsvn.open.collab.net/

Eclipse SVN Subclipse vs Subversive plugin

The SVN people have developed a plugin called Subclipse. The Eclipse people have a plugin called Subversive.

Subclipse includes the CollabNet Merge Client originally developed as part of the CollabNet Desktop - Eclipse Edition. The CollabNet Merge Client provides powerful graphical merge capabilities that leverages the merge tracking functionality that was added as part of the Subversion 1.5 release.
Subclipse includes an optional Mylyn connector that enables Mylyn to create automatic changesets based on the tasks you are working on. It also enables links to tasks when viewing history of Subversion commits.

You can see the Subclipse's screenshots in this page.

Instead Subversive have a few convenient features as:

• Full-Scale SVN Client
• Seamless Integration with Eclipse
• Advanced SVN Features
• Support of the Latest SVN Versions

You can see the Subversive's screenshots in this page.

Functionally the products are very similar as both are mature products.

Cloud service models – IaaS, PaaS, and SaaS

There are three cloud-based service models, IaaS, PaaS, and SaaS. The main features of each of these are listed here:

• Infrastructure as a Service (IaaS) provides users the capability to provision processing, storage, and network resources on demand. The customers deploy and run their own applications on these resources. Using this service model is closest to the traditional in-premise models and the virtual server provisioning models (typically offered by data center outsourcers). The onus
  of administering these resources rests largely with the customer.
• In Platform as a Service(PaaS), the service provider makes certain core components, such as databases, queues, workflow engines, e-mails, and so on, which are available as services to the customer. The customer then leverages these components for building their own applications. The service provider ensures high service levels, and is responsible for scalability, highavailability, and so on for these components. This allows customers to focus a lot more on their application's functionality. However, this model also leads to application-level dependency on the providers' services.
• In the Software as a Service(SaaS) model, typically, third-party providers using a subscription model provide end-user applications to their customers. The customers might have some administrative capability at the application level, for example, to create and manage their users. Such applications also provide some degree of customizability, for example, the customers can use their own corporate logos, colors, and many more. Applications that have a very wide user base most often operate in a self-service mode. In contrast, the provider provisions the application for the customer for more specialized applications. The provider also hands over certain application administrative tasks to the customer's application administrator (in most cases, this is limited to creating new users, managing passwords, and so on through well-defined application interfaces).

From an infrastructure perspective, the customer does not manage or control the underlying cloud infrastructure in all three service models.

The diagram illustrates who is responsible for managing the various components of a typical user application across IaaS, PaaS, and SaaS cloud service models. The column labeled Private represents the main components of a user application stack, while the following columns depict the varying levels of management responsibilities in each of the three service models. The shaded boxes are managed by the service provider, while the unshaded boxes are managed by the user.

The level of control over operating systems, storage, applications, and certain network components (for example, load balancers) is the highest in the IaaS model, while the least (or none) in the SaaS model.

What is cloud computing?

Wikipedia defines cloud computing as:

 "Cloud computing is internet-based computing in which large groups of remote servers are networked to allow the centralized data storage, and online access to computer services or resources."

The National Institute of Standards and Technology (NIST) gives the following definition of cloud computing:

"Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction."

 

There are several other broadly accepted definitions of cloud computing. Some explicitly emphasize configurability of the resources, while others include the need for rapid on-demand provisioning of resources, and still others drop the requirement of access via the internet. We define cloud computing as a model that enables the features listed here:

• Users should be able to provision and release resources on-demand;
• The resources can be scaled up or down automatically, depending on the load;
• The provisioned resources should be accessible over a network;
• Cloud service providers should enable a pay-as-you-go model, where customers are charged based on the type and quantum of  resources they consume.

Some of the implications of choosing to use the cloud for your computing needs are as follows:

• The illusion of infinite processing and storage resources, available on-demand, reduces the need for detailed advance planning and procurement processes. 
• The model promotes the use of resources as per customer needs, for example, starting small, and then increasing resources based on an increase in need. 
• The development and test environments can be provisioned on a smaller scale than production environment, and enabled only during normal business hours, to reduce costs.
• The staging environment can be provisioned for a short duration to be a replica of the production environment. This enables testing using production configuration (and scale) for improved defect resolution.
• There will be ease of scaling, both vertically and horizontally, in order to better manage spikes in demand and variations due to business cycles or time-of-day reasons, and so on.
• This encourages experimentation, by trying out new ideas and software by quickly  provisioning resources, rather than requisition for resources through time-consuming and cumbersome processes.

In addition, there are several key operational and maintenance-related implications, including no hardware maintenance or data center operations required, zero-downtime migrations and upgrades, ease of replacement of unhealthy machines, ease of implementation of high-availability and disaster recovery strategies, and many more.

What is GitHub?

GitHub is the leading code-hosting platform with literally millions of open source projects having their code hosted on it. In conjunction with Git, it provides the means for a productive development workflow and is the preferred tool among developers.

Starting with the basics of creating a repository, you can learn how to manage the issue tracker, where your project can be discussed.

GitHub provides a set of features as of example:

• Managing wiki pages: When you first create a new repository, a wiki attached to this project is also created. It is enabled by default and everyone can add new content or modify existing pages. Every time you add one or more new pages to the wiki. Similarly you can edit or remove a wiki page.
• Managing code versioning: the notion of a release is tightly tied to Git tags. You can see the existing tags, if any, from the same menu where you change a branch. Your tag name can be any arbitrary value, but it is highly recommended to follow the semantic versioning scheme. Briefly describing what semantic versioning is, a release number consists of three numbers separated by dots in the form of MAJOR.MINOR.PATCH. You should then increment the following:
• The MAJOR version when you make incompatible API changes.
• The MINOR version when you add functionality in a backwards-compatible manner.
• The PATCH version when you make backwards-compatible bug fixes.
• Organization and team management: GitHub allows you to choose among three roles for a person in an organization: owners, members, and billing managers. Owners have full access to the organization and are in the highest level of the permissions chain. Being a member is usually the default role when a new person gets in the organization. The least a member can do is create a new team and add existing team members and repositories to it. A billing manager is a user who manages the billing settings for your organization, such as updating payment information. This is a great option if regular members of your organization don't typically have access to billing resources. You can create an Organization and you can optionally invite some people to be part of the organization.
• Pull requests feature (that made GitHub so well known): GitHub UI helps you visualize clearer what is about to be merged in the default branch or the branch of your choice. Pull requests are reviewable with an enhanced diff view. You can easily revert them with a simple button on GitHub and they can be tested before merging, if a Continuous Integration service is enabled in the project.
• GitHub Pages: At the end of the year 2008, GitHub announced GitHub Pages, a static-site hosting service. Static sites have met a great rise during the past years and GitHub played a big part in it. A static site is a site that contains pages written in HTML, CSS, and Javascript. No server code, such as php, ruby, and Python is included.
• User and Repository management: As a user, there is a lot of information you can set up in your user settings page, such as associating more than one e-mail to your account, adding multiple SSH keys, or setting up two-factor authentication. Similarly, some functionalities of a repository can be set up via its settings page. For example, you can enable or disable the wiki pages, or completely disable the issue tracker. About the repository management, there are quite a few settings one can fiddle with at the repository level. To access these settings, search for the wrench icon on the right sidebar.

How to manage offline and online mode in your JFrog Artifactory

JFrog Artifactory supports two kind of offline cases: when the whole organization is disconnected from remote repositories and when one or more remote repositories needs to be put offline.

When the artifactory server (or single repo) is not possible the artifact downloads from remote repositories as maven repository (https://mvnrepository.com/).

It is possible to set your JFrog Artifactory in "Global Offline Mode" via Admin Console Web. In detail, select Admin -> Configuration -> General and flag the checkbox with label "Global Offline Mode". See the screenshot below:

Only an user with admin grant can set on/off this mode. Of course when "Global Offline Mode" is enabled, options online/offline on individual repositories are not considered because all repositories
become offline.

Instead, you can configure your artifactory server online and some repositories offline. In this case, select Admin -> Repositories -> Remote, choose the repository and flag the checkbox with label "Offline". See the screenshot below:

Again, you need a user with admin grant can set on/off this mode.

What is devOps?

DevOps is, by definition, a field that spans several disciplines. It is a field that is very practical and hands-on, but at the same time, you must understand both the technical background and the nontechnical cultural aspects.

The word "DevOps" is a combination of the words "development" and "operation". This wordplay already serves to give us a hint of the basic nature of the idea behind DevOps. It is a practice where collaboration between different disciplines of software development is encouraged.

The origin of the word DevOps and the early days of the DevOps movement can be tracked rather precisely: Patrick Debois is a software developer and consultant with experience in many fields within IT. He was frustrated with the divide between developers and operations personnel. He tried getting people interested in the problem at conferences, but there wasn't much interest initially.

In 2009, there was a well-received talk at the O'Reilly Velocity Conference: "10+ Deploys per Day: Dev and Ops Cooperation at Flickr." Patrick then decided to organize an event in Ghent, Belgium, called DevOpsDays. This time, there was much interest, and the conference was a success. The name "DevOpsDays" struck a chord, and the conference has become a recurring event. DevOpsDays was abbreviated to "DevOps" in conversations on Twitter and various Internet forums.
The DevOps movement has its roots in Agile software development principles. The Agile Manifesto was written in 2001 by a number of individuals wanting to improve the then current status quo of system development and find new ways of working in the software development industry. The following is an excerpt from the Agile Manifesto, the now classic text, which is available on the Web at http://agilemanifesto.org/:

"Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more."

In light of this, DevOps can be said to relate to the first principle, "Individuals and interactions over processes and tools."

This might be seen as a fairly obviously beneficial way to work—why do we even have to state this obvious fact? Well, if you have ever worked in any large organization, you will know that the opposite principle seems to be in operation instead. Walls between different parts of an organization tend to form easily, even in smaller organizations, where at first it would appear to be impossible for such walls to form.

DevOps, then, tends to emphasize that interactions between individuals are very important, and that technology might possibly assist in making these interactions happen and tear down the walls inside organizations. This might seem counterintuitive, given that the first principle favors interaction between people over tools, but my opinion is that any tool can have several effects when used. If we use the tools properly, they can facilitate all of the desired properties of an Agile workplace.

A very simple example might be the choice of systems used to report bugs. Quite often, development teams and quality assurance teams use different systems to handle tasks and bugs. This creates unnecessary friction between the teams and further separates them when they should really focus on working together instead. The operations team might, in turn, use a third system to handle requests for deployment to the organization's servers.
An engineer with a DevOps mindset, on the other hand, will immediately recognize all three systems as being workflow systems with similar properties. It should be possible for everyone in the three different teams to use the same system, perhaps tweaked to generate different views for the different roles. A further benefit would be smaller maintenance costs, since three systems are replaced by one.
Another core goal of DevOps is automation and Continuous Delivery. Simply put, automating repetitive and tedious tasks leaves more time for human interaction, where true value can be created.

How to resolve some git errors

This post will help the readers a lot because the errors mentioned can occur very frequently.

Remote origin already exists

This error occurs when you already have a remote repository specified and the remote origin removed and added. Example:

$ git remote rm origin
$ git remote add origin https://gitserver.com/scm/myproject.git

Git push fails with rejected error

This error occurs because you didn't execute git pull before git push. Example:

$ git pull
$ git push

Git push fails caused by "fatal: The remote end hung up unexpectedly"

This one is common and you should check whether your remote URL is correct and Git has access to the remote repository. I suggest add (if not already setted) the origin; else set the correct origin.

Restoring a changed file to its last committed state

Run git checkout followed by the filename and you will lose your changes. However, this will be restored as a clean copy of the file. Example:

$ git checkout fileName

Unstaging a file

Did you run git add too soon? Run git reset HEAD followed by the filename to unstage it:

$ git reset HEAD fileName

How to fix the most recent commit message

The –amend option will edit a commit message:

$ git commit --amend

The editor will open to edit the last message.

Reset the most recent commit

There are two ways to do this: with and without your changes.
1) Without losing changes:

$ git reset HEAD~1

2) By losing changes:

$ git reset --hard HEAD~1

I found a bug after releasing the product but it was in the commit that I did a long time ago

In this case, you should not use git reset because it rewrites the history and the product is already released. Therefore, you should make a commit that reverts the buggy commit and pushes it to
share with your colleagues:

$ git revert 17cc9433abcf23c42aef6b9aad24b5fcfc353f7c

There are many garbage files in the working directory. How to delete them?

In this situation, the files are not maintained by Git, so you have to use git clean:
1) To check the files that will be removed

$ git clean -n

2) Now remove them:

$ git clean -f

I think I made a mistake while resolving conflicted files. How do I restore it to the state just after git merge?

To do this, you can use git checkout:

$ git checkout --merge fileName

Gitindex file is corrupt

No need to worry. This one is rare but can be annoying! Git will display the error as "bad index file sha1 signature: fatal: index file corrupt". You just have to remove the backup index file; remove it, and then reset the repository:

$ mv .git/index .git/indexOLD

$ git reset

Git refuses to start a merge/pull command.

The typical error messages look like this:

• Error: The myfile.txt entry is not up to date; it cannot be merged.
• Error: The myfile.txt entry will be overwritten by the merge command.

To resolve this, perform the following steps:
1. Stash the changes or throw them out:

$ git stash save "a message"
$ git checkout myfile.txt

2. Check that the changes are staged:

$ git status

3. Bring the changes from the remote repository:

$ git pull

4. Repopulate if you made a stash:

$ git stash pop

How to use git bisect

The git bisect command allows you to run a binary search through the commit history to find a commit that has an issue. For example, you pulled the last commits and the website isn't working anymore. You know that before the last pull everything was okay. So you have to find the commit ID before it crashes and the last ID after the pull:

$ git bisect start
$ git bisect bad <commit_id_after_pull>
$ git bisect good <commit_id_before_pull>

Now, the bisecting loop begins and Git will check for an alternative commit.
Reset the given commit and tell Git whether the website is working:

$git bisect <bad_commit_id>

Git will search again and again to find which commit crashed the website:

$ git show <commit_id>

Instead of trying to locate a bug inside all your files, you have a shortened list of files.

How to reset a git commit via bash script 

If you don't want to reset to a given commit and test your software, you can create a bash script and tell Git to use it. The script has to return 0 if the condition is fulfilled, and nonzero if it isn't.

check_file.sh

#!/bin/bash
FILE=$1
If [ -f $FILE];
then
    exit 0;
else
    exit 1;
fi

Now it's time to run git bisect to specify the last 10 commits:

$ git bisect start HEAD HEAD~10
$ git bisect run ./check_file.sh MyFile.java

Bisect algorithm

The algorithm used by git bisect always returns the commit that is at the middle position of the array.
In the following diagram, you will see how the algorithm found the good commit in three steps:

1. The Commit6 option is selected by Git. After checking it, you tell Git that it's good.
2. Git reduces the array because if Commit6 is good, then every commit between Commit1 and Commit6 is good too.
3. Then Git asks you to test Commit9, and you say that it's good too.
4. So the error can only be inside Commit10 and Commit11.

How to solving merge conflits with git

When you are working with several branches, a conflict will probably occur while merging them. It appears if two commits from different branches modify the same content and git isn't able to merge them. If it occurs, Git will mark the conflict and you have to resolve it.
For example, Developer1 modified the myfile.txt on a feature branch and Developer2 has to edit it on another branch. When Developer2 merges the two branches, the conflict occurs.
Git will tell you to edit the file to resolve the conflict. In this file, you will find the following:

<<<<<<< HEAD
Changes from Developer2
=======
Changes from Developer1
>>>>>>> 5df2fcdc89e0a33fcf8cbbbbd89cb8eabbdb61b7

The <<<<<<< characters indicate the start of the merge conflict, the ====== characters indicate the break points used for comparison, and >>>>>>> indicate the end of the conflict.
To resolve a conflict, you have to analyze the differences between the two changes and merge them manually. Don't forget to delete the signs added by Git. After resolving it, simply commit the changes.
If your merge conflict is too complicated to resolve because you can't easily find the differences, Git provides a useful tool to help you.
The "git diff" and "git mergetool" help you to find differences. Other tools to visually compare and merge files are:

• SourceGear DiffMerge
• kdiff3
• p4merge
• IntelliJ IDEA

How to configure git alias

Git allows you to use aliases for command lines. The alias concept is similar to linux. Setup git alias is very fast: in your $HOME edit the .gitconfig file and add the following text:

[alias]
    l = log --pretty=format:"%C(yellow)%h\\ %ad%Cred%d\\ %Creset%s%Cblue\\ [%cn]" --decorate --date=short

Now if you run the following command:

$ git l

see the output of alias "l". Now you are ready to create a new customer alias or add other aliases available in web.

Examples of aliase are:

    l = log --pretty=format:"%C(yellow)%h\\ %ad%Cred%d\\ %Creset%s%Cblue\\ [%cn]" --decorate --date=short
    a = add    
    ap = add -p
    c = commit --verbose
    cm = commit -m
    cam = commit -a -m
    d = diff
    ds = diff --stat
    dc = diff --cached
    s = status -s
    co = checkout
    cob = checkout -b
    cmp = "!f() { git add -A && git commit -m "$@" && git push; }; f"
    la = "!git config -l | grep alias | cut -c 7-"

How to rewrite commit history with git

Someone accidentally commits a huge binary file with a thoughtless git add ., and you want to remove it everywhere. Perhaps you accidentally committed a file that contained a password, and you want to make your project open source. filter-branch is the tool you probably want to use to scrub your entire history. The --tree-filter option runs the specified command after each checkout of the project and then recommits the results. 

Examples:

1) To remove a file named mypasswords.txt from your entire history, you can use the --tree-filter option to filter-branch: 

$ git filter-branch --tree-filter 'rm -f mypasswords.txt' HEAD
Rewrite 802a096d79b9b5872544a6b35d6a52cbdf55274a (21/21)
Ref 'refs/heads/master' was rewritten 

2) If you want to remove all accidentally committed editor backup files, you can run something like

$ git filter-branch --tree-filter 'rm -f *~' HEAD.

--index-filter option

The --index-filter is another option similar to the tree filter but does not check out the tree, which makes it much faster.

$ git filter-branch --index-filter 'git rm --cached --ignore-unmatch myfilename.txt' HEAD

The --ignore-unmatch option is needed because "git rm" will fail if the file is absent from the tree.

Canceling a commit with git

The git revert command allows you to cancel your last unpushed commit. The type of cancel is only logical because Git doesn't drop phisically the commit but it creates a new commit that executes the opposite of your commit. A pushed commit is irreversible, so you cannot change it.

Example

The following example illustrates how to remove last pushed commit. First step, let's have a look at the last commits:

$ git log

commit dc2d9f3deda6f49902c1879b7b861fac51683865

Author: infoamodomio <infoamodomio@infoamodomio.com>

Date:   Thu May 25 12:19:01 2017 +0200

    Added a new file

Second step, We want to cancel the dc2d9f… commit:

$ git revert dc2d9f

Canceling this commit isn't necessary to enter the full commit ID, but just the first characters. Git will find it, but you will have to enter at least six characters to be sure that there isn't another commit that starts with the same characters.

How to edit a commit with git

It is possible three actions to edit a commit:

1. Change the comment;
2. Add one or more files in a commit;
3. Remove one or more files in a commit.

Examples

1) If you want to edit the description of your last commit, use the following line: 

 $ git commit --amend

2) Let's suppose that your last commit contains buggy code; you can specify that your changes on the file are part of the last commit:

 $ git add file.txt
 $ git commit -v -amend

3) Now I want to remove a file I included accidentally in the last commit (because this file deserves a new commit):

 $ git reset HEAD^1 file.txt
 $ git commit --amend -v
 $ git commit -v file.txt