How to use Subversion from command line

By emiviada in SCM, Subversion, VCS 11 Comments

Here we will see how to use Subversion from CLI (Command Line Interface).

As you may know, there are SVN clients like Tortoise for Windows or RabbitVCS for Linux, but in this post we will only cover CLI (my favourite way ;-)).

Initialize a project work copy in my local machine: svn checkout

To get a work copy of source files in their last version we need to execute a process to copy all the files in our file system, this is accomplished with the checkout command:

1
user@unix:$ svn checkout https://svn.hasheado.com/svn/hasheado/trunk hasheado-repo --username=hasheado

The above command will copy all files in our file system and all files are ready to be edited. Now, you can edit existing files, create new files and/or directories or remove files locally. Keep on mind that everything change we make, it only affects our local copy until we commit the changes to the svn repository.

Add files/directories: svn add

We can add a new file to the repository after create it and editing it in our local copy, or well, add a directory with or without content using the svn add command. This command will add the files/directories from your local copy and they will be added to the repo in the next commit. Also, we can change our minds and revert whatever we do not want using the svn revert command.

1
2
user@unix:$ svn add css/style.css
user@unix:$ svn revert

View file information: svn blame and svn cat

We can see the information about the author and revision number for specific files, using the svn blame FILENAME command; each line in the file is displayed at the beginning with the author (svn username) and revision number of the last change for the line.

If we want to see the differences in an specific file before to commit our changes, we can run the svn cat command.

Unlock a work copy

Sometimes we can see a “working copy locked” error. So, to unlock it, we can run:

1
user@unix:$ svn cleanup

Copy a file/directory: svn copy

Sometimes we have the need to just copy a file, to do this we can use the svn copy command as we can see below:

1
user@unix:$ svn copy SRC DST

Delete a file/directory: svn delete

If we want to delete a file or directory we can use:

1
user@unix:$ svn delete FILENAME

And to persist the deletion we need to commit.

Export a directory without .svn files: svn export

With this command we can extract a work copy with no version (without .svn files), to export a directory without .svn files we can run:

1
user@unix:$ svn export [-r REV] [PATH]

This will export a non-version work copy from the specified repository, we can specify the version as well, if no version is specified the head revision (HEAD) is exported. If the PATH is omitted, the last url is used to export.

1
user@unix:$ svn export PATH1 PATH2

SVN help

We can use the SVN help to see how to use every command:

1
user@unix:$ svn help [SUBCOMMAND...]

Send changes to repository

After we have made the changes locally in our files and/or directories, we should commit those changes to the repository.

Commit the changes: svn commit

To commit the changes to the repo:

1
user@unix:$ svn commit -m "Type your comment here" [files]

If we do not include any comment in the commit, we should add it in the default text editor which is triggered before SVN can complete the commit. All commits are logged into the SVN log.

Show commit logs: svn log

If we want to see the history of files or directories in our local copy or in the repo to track the revisions we can run:

1
user@unix:$ svn log [PATH]

The result is information about the files/directories, starting with the most current revision and showing information like the commit’s messages and authors.

Merge changes: svn merge

We can run the svn merge command to tell to Subversion that it should merge the last versions of the repo files into our local work copy.

Working with the repository

Create a new directory: svn mkdir

To create a new directory in your local work copy:

1
user@unix:$ svn mkdir PATH

Or, to create a new directory in the repo:

1
user@unix:$ svn mkdir URL

The end part of PATH or URL determines the new directory’s name. The new directory in the repo is created with an inmediate commit which requires a commit’s message.

Move a file/directory: svn move

We can move a file/directory using the svn move SRC DST command, with SRC being the source and DST the destiny. This command is equal to make a svn copy followed by a svn delete.

Resolve conflicts: svn resolved

In some situations we can get a conflict while we update our work copy. If this is the case, we need to resolve the conflict and then mark it as resolved. To do that we need to run:

1
user@unix:$ svn resolved PATH

SVN status

A good practice is to review our changes before to commit them, for that we can run svn status to print the file/directory status in our local copy.

Update our local copy: svn update

Another good practice is to update the local work copy every time we start working in the project, running:

1
user@unix:$ svn update [PATH...]

The updated items with their status are displayed as:
* A = A file was added to the local copy.
* U = A file was updated in our local copy.
* D = A file was deleted in our local copy.
* R = A file was replaced in our local copy.
* G = A file was successfully merged.
* C = A file has conflicts that we need to resolve.

Branching and Tagging

The project trunk is normally the main development thread, while the branches are used to different variants of that main development thread. For instance, when we want to build a new feature we can create a new branch to work on it. A tag is a way to group stable versions of the project. Although, the branches and tags are created using the svn copy command, their concepts are totally different. To create a branch/tag we have to run:

1
user@unix:$ svn copy SRC DST -m "Type your message here"

How to send emails with Symfony 1.3 / 1.4

By emiviada in PHP, SwiftMailer, Symfony 1.x 0 Comment

In this post we will see how to send emails with Swift Mailer through Symfony.

As we mentioned in an earlier post, Symfony comes with an already integrated mailer library. And, send an email is as simple as we can see below:

1
2
3
4
<?php
public function executeSendEmail() {
    $this->getMailer()->composeAndSend('from@example.com', 'to@example.com', 'Subject', 'Body');
}

Or, you can chose for compose the message and then send it with the Send() method:

1
2
3
4
5
<?php
public function executeSendEmail() {
    $this->getMailer()->compose('from@example.com', 'to@example.com', 'Subject', 'Body');
    $this->getMailer()->send();
}

Furthermore, if we need to add a little more of complexity like attach a file, it is as simple as we can see below:

1
2
3
4
5
6
<?php
public function executeSendEmail() {
    $this->getMailer()->compose('from@example.com', 'to@example.com', 'Subject', 'Body')
        ->attach(Swift_Attachment::fromPath('/path/to/a/file.zip'));
    $this->getMailer()->send();
}

As we can observe in the previously used methods Symfony handles mailing issues with a Mailer object, which is got it with the getMailer() method, already ready to use in the controller due to that the mailer object already is part of the Symfony’s core.

Configuration

By default, the send() method tries to use the local SMTP server to send the message, but, of course, as a lot of Symfony stuff this is totally configurable.

As we mentioned previously the Mailer object is part of the Symfony’s core. These objects are automatically built, configured and handled them by the framework. All of the core objects are configurable by the factories.yml file.

The default configuration looks like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
mailer:
  class: sfMailer
  param:
    logging: %SF_LOGGING_ENABLED%
    charset: %SF_CHARSET%
    delivery_strategy: realtime
    transport:
      class: Swift_SmtpTransport
      param:
        host: localhost
        port: 25
        encryption: ~
        username: ~
        password: ~

When a new application is built, the factories.yml file overwrites the default configuration with some sensitive environments variables:

1
2
3
4
5
6
7
8
9
test:
  mailer:
    param:
      delivery_strategy: none

dev:
  mailer:
    param:
      delivery_strategy: none

The delivery_strategy option tells to the framework how to deliver the messages. By default, Symfony comes with 4 different strategies:

  • realtime: The messages are delivered in real time.
  • single_address: The messages are delivered to just one single email address.
  • spool: The messages are stored in a queue.
  • none: The messages are just ignored.

It does not matter what the strategy is, the messages are always logged them in the log and they are available in the “mailer” tab in the web debug toolbar.

Mail Transport

The emails are always send them through a transport. You can configure the transport that you want just editing the factories.yml file. The default configuration is:

1
2
3
4
5
6
7
8
transport:
  class: Swift_SmtpTransport
  param:
    host:       localhost
    port:       25
    encryption: ~
    username:   ~
    password:   ~

We can chose between 3 different classes:

  • Swift_SmtpTransport: Uses the SMTP server to send messages.
  • Swift_SendmailTransport: Uses sendmail to send messages.
  • Swift_MailTransport: Uses the PHP native function mail() to send the messages.

In the “Transport Types” section into the official Swift Mailer documentation we can find everything we need about the transport classes and their different parameters.

Source: Symfony’s site