Difference between revisions of "Working with SVN"

From Inkscape Wiki
Jump to navigation Jump to search
(Well, the template includes the category)
 
(16 intermediate revisions by 12 users not shown)
Line 1: Line 1:
(This began a copy of [[WorkingWithCVS]]; bear with us as it is updated for SVN)
{{Outdated}}
 
'''This page is no longer relevant as Inkscape uses Bazaar for version control now. Please see [[Working with Bazaar]] for new instructions.'''
 
(This began as a copy of [[WorkingWithCVS]]; bear with us as it is updated for SVN)


== Subversion (SVN) Basics ==
== Subversion (SVN) Basics ==
Line 35: Line 39:
To check out a copy of Inkscape from the SVN repository, you may use the following command:
To check out a copy of Inkscape from the SVN repository, you may use the following command:


  svn checkout https://svn.sourceforge.net/svnroot/inkscape/inkscape/trunk inkscape
  svn checkout https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk inkscape


Here are what the options mean:
Here are what the options mean:
Line 41: Line 45:
"checkout" ("co" means the same thing) specifies the action to take (check out a working copy).
"checkout" ("co" means the same thing) specifies the action to take (check out a working copy).


"https://svn.sourceforge.net/svnroot/inkscape/inkscape/trunk" is a repository URL; in this case, it refers to the "main" development branch for Inkscape.
"https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk" is a repository URL; in this case, it refers to the "main" development branch for Inkscape. Other repository URLs are:
 
* http://inkscape.svn.sourceforge.net/svnroot/inkscape/doc-docbook/trunk - contains the docbook source of the Inkscape tutorials


"inkscape" is the name of the directory to check out into
"inkscape" is the name of the directory to check out into
Line 72: Line 78:
  The changes in your version will be here
  The changes in your version will be here
  =======
  =======
  The changes the other person will be here
  The changes by the other person will be here
  >>>>>>> ''some version here''
  >>>>>>> ''some version here''


Line 88: Line 94:


-x -u3 specifies which format to use (a unified diff with three lines of context).  This is the recommended diff format.
-x -u3 specifies which format to use (a unified diff with three lines of context).  This is the recommended diff format.
If it doesn't work (on Subversion 1.4.5 for Windows) try:
svn diff -x -u > filename


This will create a file describing the changes you have made, though if you have created new files as part of your changes, you will need to include those separately too when emailing them to the list or another developer for inclusion.
This will create a file describing the changes you have made, though if you have created new files as part of your changes, you will need to include those separately too when emailing them to the list or another developer for inclusion.
Line 93: Line 102:
=== Automatic Commit Diff ===
=== Automatic Commit Diff ===


[ fixme: how to do this in SVN? ]
[ fixme: how to do this in SVN?
  SVN_EDITOR instead of CVSEDITOR
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.confarea.opts.config ]


To always generate a diff when you commit to CVS, set the environment variable "CVSEDITOR" to the following script:
To always generate a diff when you commit to CVS, set the environment variable "CVSEDITOR" to the following script:
Line 129: Line 140:
If you have write access to the repository, you can commit your changes like this:
If you have write access to the repository, you can commit your changes like this:


Before you commit, please make sure that you describe the changes you have made in the [[ChangeLog]] file at the top-level directory.
svn commit -m "Your description of your changes goes here"


  svn commit -m "Your description of your changes goes here"
or, to commit only some changed files but not others:
 
  svn commit -m "Your description of your changes goes here" path/file1.cpp path/file2.cpp
 
Tip: even if you are committing directly, you still might want to generate a diff.  It's a good reference to look at when you're filling out the change description, since it will remind you of all the changes you've made.


Tip: even if you are committing directly, you still might want to generate a diff. It's a good reference to look at when you're filling out the [[ChangeLog]], since it will remind you of all the changes you've made.
'''Important:''' check that the (unit) tests still work if you touched anything that might possibly, in some way, affect them. If you changed anything that is in no way covered by unit tests, or if you fixed a bug that wasn't exposed by existing unit tests, consider making new (unit) tests. See [[TestingInkscape]] for information on how to execute and make tests.


=== Adding Files to the Repository ===
=== Adding Files to the Repository ===
Line 148: Line 163:


  svn remove ''files to remove go here''
  svn remove ''files to remove go here''
[[Category:Developer Documentation]]

Latest revision as of 04:39, 10 July 2016

This page is outdated. It is kept for historical reasons, e.g. to document specific decisions in Inkscape development.

This page is no longer relevant as Inkscape uses Bazaar for version control now. Please see Working with Bazaar for new instructions.

(This began as a copy of WorkingWithCVS; bear with us as it is updated for SVN)

Subversion (SVN) Basics

This node discusses the basics of using SVN.

For information on more advanced usage, see:

Concepts

The Repository

SVN stores source code in a shared repository (in our case on Sourceforge's server). The repository contains all past and present versions of the code, and is shared by everyone.

Your Working Copy

To work with the source code, SVN requires you to check out a working copy. This copy is private, so you can make and test any changes you like without disturbing anyone else.

If you have write access to the repository, when you are finished making your changes, you may commit your changes to the shared repository, making them available to everyone.

Alternately, you may generate a file containing the changes you made (a diff), and send it to a developer with write access to be incorporated.

You can check out as many working copies as you want; they take up only your own disk space, and they are completely independent of each other.

If you no longer need a working copy, you may simply delete it.

Getting Started

Setting Up

How Do I Check Out a Working Copy?

To check out a copy of Inkscape from the SVN repository, you may use the following command:

svn checkout https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk inkscape

Here are what the options mean:

"checkout" ("co" means the same thing) specifies the action to take (check out a working copy).

"https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk" is a repository URL; in this case, it refers to the "main" development branch for Inkscape. Other repository URLs are:

"inkscape" is the name of the directory to check out into

Now What?

You should have a complete working copy in the inkscape directory. You can cd to it and try compiling.

Note: If it is a fresh checkout, you will need to run the ./autogen.sh shell script at the top level to create files needed to compile

When you're inside the working copy, you won't normally need to specify the repository URL, because SVN remembers where the working copy came from.

Note that a Subversion command only applies to the current directory and (possibly) any subdirectories. Normally (particularly for updates, diffs, and checkins), you will want to run the command from the top level of the project.

Bringing Your Working Copy Up-To-Date

Your working copy will not automatically include changes others have made to the repository since you checked it out.

To update your working copy, use this command:

svn update

Dealing with Conflicts

If you've made changes to your working copy, what happens if you update after someone has commited changes to the same files?

Normally, SVN can work this out on its own. Sometimes you have to help it along, though. If SVN says there were conflicts, look for which files have a C next to them in its progress output. Some of those may have unresolved conflicts. You can also search for '=======' in the files themselves to find any unresolved conflicts.

<<<<<<< filename
The changes in your version will be here
=======
The changes by the other person will be here
>>>>>>> some version here

Sometimes you will keep one set of changes and discard the other, and sometimes you will combine the two. It will require a judgement call on your part either way. Talk to the person who made the other set of changes or ask on the mailing list if it's unclear what's going on. Remember that SVN is no substitute for communication.

Also, always make sure to build and test after an update to make sure that the combined changes work as intended!

Generating a Diff

(Always update before generating a diff!)

From the top-level directory, run the command:

svn diff -x -u3 > filename

-x -u3 specifies which format to use (a unified diff with three lines of context). This is the recommended diff format.

If it doesn't work (on Subversion 1.4.5 for Windows) try:

svn diff -x -u > filename

This will create a file describing the changes you have made, though if you have created new files as part of your changes, you will need to include those separately too when emailing them to the list or another developer for inclusion.

Automatic Commit Diff

[ fixme: how to do this in SVN?

 SVN_EDITOR instead of CVSEDITOR

http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.confarea.opts.config ]

To always generate a diff when you commit to CVS, set the environment variable "CVSEDITOR" to the following script:

#!/bin/bash
# get rid of redhat 9 locale ugliness
unset LC_CTYPE
# Turn on ro access (to stop multiple locks) for local roots
grep @ CVS/Root >/dev/null 2>&1 || export CVSREADONLYFS=1
# Tell the user what's going on
echo Building diff...
cvs diff -up 2>/dev/null | perl -ne 'print "CVS: $_" unless /^\?/' >> "$1"
exec ${EDITOR:-vi} "$1"

If the above script is named "~/bin/cvsdiffvi", then assuming you run the bash shell, you can add the following your .bashrc file:

export CVSEDITOR=~/bin/cvsdiffvi

Now, every time you commit, the entire diff will be visible to you as you write your commit comments.

Applying a Diff

A diff file can be applied to the codebase using the 'patch' command.

If the diff was made as inkscape/src/thingy.cpp and you're in the "inkscape" directory, you'll want to use the command:

patch -p1 < thingy.diff

Depending on how many path elements are part of the diff, you'll need to strip them with -p1, -p2, etc.

Committing your Changes

(Always update before committing!)

If you have write access to the repository, you can commit your changes like this:

svn commit -m "Your description of your changes goes here"

or, to commit only some changed files but not others:

svn commit -m "Your description of your changes goes here" path/file1.cpp path/file2.cpp

Tip: even if you are committing directly, you still might want to generate a diff. It's a good reference to look at when you're filling out the change description, since it will remind you of all the changes you've made.

Important: check that the (unit) tests still work if you touched anything that might possibly, in some way, affect them. If you changed anything that is in no way covered by unit tests, or if you fixed a bug that wasn't exposed by existing unit tests, consider making new (unit) tests. See TestingInkscape for information on how to execute and make tests.

Adding Files to the Repository

To add new files as part of your commit, you will need to run:

svn add files and directories to add go here

Before you commit. This also goes for new directories.

The actual addition or removal will not take effect until you commit.

Removing Files from the Repository

svn remove files to remove go here