https://wiki.inkscape.org/wiki/api.php?action=feedcontributions&user=Chris+Morgan&feedformat=atomInkscape Wiki - User contributions [en]2024-03-29T13:19:05ZUser contributionsMediaWiki 1.36.1https://wiki.inkscape.org/wiki/index.php?title=ReleaseNotes&diff=55113ReleaseNotes2009-12-07T16:33:23Z<p>Chris Morgan: Fixed double redirect</p>
<hr />
<div>#redirect [[Release notes]]</div>Chris Morganhttps://wiki.inkscape.org/wiki/index.php?title=Release_Notes&diff=55111Release Notes2009-12-07T16:32:27Z<p>Chris Morgan: Fixed redirect</p>
<hr />
<div>#redirect [[Release notes]]</div>Chris Morganhttps://wiki.inkscape.org/wiki/index.php?title=Working_with_SVN&diff=55095Working with SVN2009-12-06T05:14:23Z<p>Chris Morgan: Working with Bazaar</p>
<hr />
<div>This page is no longer relevant as Inkscape uses Bazaar for version control now. Please see [[Working with Bazaar]] for new instructions.<br />
<br />
(This began a copy of [[WorkingWithCVS]]; bear with us as it is updated for SVN)<br />
<br />
== Subversion (SVN) Basics ==<br />
<br />
This node discusses the basics of using SVN.<br />
<br />
For information on more advanced usage, see:<br />
<br />
* [[WorkingWithSVNBranches]] - making branches and merging between them<br />
<br />
=== Concepts ===<br />
<br />
==== The Repository ====<br />
<br />
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.<br />
<br />
==== Your Working Copy ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
If you no longer need a working copy, you may simply delete it.<br />
<br />
=== Getting Started ===<br />
<br />
==== Setting Up ====<br />
<br />
==== How Do I Check Out a Working Copy? ====<br />
<br />
To check out a copy of Inkscape from the SVN repository, you may use the following command:<br />
<br />
svn checkout https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk inkscape<br />
<br />
Here are what the options mean:<br />
<br />
"checkout" ("co" means the same thing) specifies the action to take (check out a working copy).<br />
<br />
"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:<br />
<br />
* http://inkscape.svn.sourceforge.net/svnroot/inkscape/doc-docbook/trunk - contains the docbook source of the Inkscape tutorials<br />
<br />
"inkscape" is the name of the directory to check out into<br />
<br />
==== Now What? ====<br />
<br />
You should have a complete working copy in the '''inkscape''' directory. You can cd to it and try compiling.<br />
<br />
: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<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Bringing Your Working Copy Up-To-Date ===<br />
<br />
Your working copy will not automatically include changes others have made to the repository since you checked it out.<br />
<br />
To ''update'' your working copy, use this command:<br />
<br />
svn update<br />
<br />
=== Dealing with Conflicts ===<br />
<br />
If you've made changes to your working copy, what happens if you update after someone has commited changes to the same files?<br />
<br />
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.<br />
<br />
<<<<<<< ''filename''<br />
The changes in your version will be here<br />
=======<br />
The changes by the other person will be here<br />
>>>>>>> ''some version here''<br />
<br />
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.<br />
<br />
Also, always make sure to build and test after an update to make sure that the combined changes work as intended!<br />
<br />
=== Generating a Diff ===<br />
<br />
('''Always''' update before generating a diff!)<br />
<br />
From the top-level directory, run the command:<br />
<br />
svn diff -x -u3 > filename<br />
<br />
-x -u3 specifies which format to use (a unified diff with three lines of context). This is the recommended diff format.<br />
<br />
If it doesn't work (on Subversion 1.4.5 for Windows) try:<br />
svn diff -x -u > filename<br />
<br />
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.<br />
<br />
=== Automatic Commit Diff ===<br />
<br />
[ fixme: how to do this in SVN?<br />
SVN_EDITOR instead of CVSEDITOR<br />
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.confarea.opts.config ]<br />
<br />
To always generate a diff when you commit to CVS, set the environment variable "CVSEDITOR" to the following script:<br />
<br />
#!/bin/bash<br />
# get rid of redhat 9 locale ugliness<br />
unset LC_CTYPE<br />
# Turn on ro access (to stop multiple locks) for local roots<br />
grep @ CVS/Root >/dev/null 2>&1 || export CVSREADONLYFS=1<br />
# Tell the user what's going on<br />
echo Building diff...<br />
cvs diff -up 2>/dev/null | perl -ne 'print "CVS: $_" unless /^\?/' >> "$1"<br />
exec ${EDITOR:-vi} "$1"<br />
<br />
If the above script is named "~/bin/cvsdiffvi", then assuming you run the bash shell, you can add the following your .bashrc file:<br />
<br />
export CVSEDITOR=~/bin/cvsdiffvi<br />
<br />
Now, every time you commit, the entire diff will be visible to you as you write your commit comments.<br />
<br />
=== Applying a Diff ===<br />
<br />
A diff file can be applied to the codebase using the 'patch' command.<br />
<br />
If the diff was made as <code>inkscape/src/thingy.cpp</code> and you're in the "inkscape" directory, you'll want to use the command:<br />
<br />
patch -p1 < thingy.diff<br />
<br />
Depending on how many path elements are part of the diff, you'll need to strip them with -p1, -p2, etc.<br />
<br />
=== Committing your Changes ===<br />
<br />
('''Always''' update before committing!)<br />
<br />
If you have write access to the repository, you can commit your changes like this:<br />
<br />
svn commit -m "Your description of your changes goes here"<br />
<br />
or, to commit only some changed files but not others:<br />
<br />
svn commit -m "Your description of your changes goes here" path/file1.cpp path/file2.cpp<br />
<br />
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.<br />
<br />
'''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.<br />
<br />
=== Adding Files to the Repository ===<br />
<br />
To add new files as part of your commit, you will need to run:<br />
<br />
svn add ''files and directories to add go here''<br />
<br />
Before you commit. This also goes for new directories.<br />
<br />
The actual addition or removal will not take effect until you commit.<br />
<br />
=== Removing Files from the Repository ===<br />
<br />
svn remove ''files to remove go here''<br />
<br />
[[Category:Developer Documentation]]</div>Chris Morganhttps://wiki.inkscape.org/wiki/index.php?title=Working_with_Bazaar&diff=55093Working with Bazaar2009-12-06T05:14:06Z<p>Chris Morgan: lp:inkscape is ready, we're using it (removed warning)</p>
<hr />
<div>==Bazaar concepts==<br />
<br />
It is assumed that you are familiar with the basic concepts of version control, like working copy, committing, updating, conflicts. There will be a section that explains the basic functionality soon.<br />
<br />
* '''Branch''' is a working copy of the project's code. Typically you use one branch per set of related changes, for example a new output extension. Once your work is finished, you ''merge'' your branch into a larger project. Initially, there is only one branch, the trunk; all other branches are its (probably indirect) descendants. To create a new branch, you have to copy an existing one.<br />
* '''Checkout''' is a copy of code contained in a branch that is not stored on your computer (a remote branch). Committing to a checkout will immediately apply the changes to the remote branch. Commits will not succeed if somebody else<br />
* When branches A and B have a common ancestor branch but each contain changes not present in the other, they have '''diverged'''. For example, when you work on an improved rectangle tool in your own branch and at the same time somebody else applies a PDF export bugfix to the trunk, your rectangle tool branch becomes diverged from the trunk.<br />
* '''Trunk''' is the main branch, which represents cutting-edge working code. You should start from it when doing any new development.<br />
* '''Merge''' is the process of reconciling changes made between two branches since they diverged. This operation is asymmetric. When you merge A into B, all changes made to A since it was branched from B are applied to B. A is not changed. When you work on some feature, you typically work in a branch, periodically merging the trunk into your branch (to sync up with the latest changes), then you merge your work into the trunk. Merging is similar to applying a patch - it only changes your working copy. To apply a merge, you need to commit the changes it introduced. Merging un-diverges branches.<br />
* '''Repository''' is a place where branches of a project are stored. Having a shared repository reduces the storage requirements of multiple branches of one project. Instead of O(number of branches) space, they take roughly O(size of changes).<br />
* '''Bind''' is the process of converting a non-diverged local branch into a checkout.<br />
* '''Push''' is the process of publishing an exact copy (a mirror) of your branch in some other location. The difference between pushing and checkouts is that a checked out remote branch is updated every time you commit, while a pushed remote branch is updated only when you push to it. You can only push to a branch if the mirror has not diverged from your local copy. This can happen if more than 1 person can push to the same location.<br />
* '''Pull''' is the process of creating a local exact copy (mirror) of a branch, in principle a reverse of pushing.<br />
<br />
==First steps==<br />
<br />
First you need to tell Bazaar your name. This will appear on all your commits. You should use your real e-mail, but you can obfuscate it if you are afraid of spam.<br />
<br />
Obfuscated e-mail example:<br />
$ bzr whoami "John Q. Public <john dot q dot public at-sign bigmail dot com>"<br />
Unobfuscated e-mail example: <br />
$ bzr whoami "John Q. Public <john.q.public@bigmail.com>"<br />
<br />
The basic usage:<br />
$ bzr branch lp:inkscape<br />
$ cd inkscape<br />
$ bzr bind lp:inkscape<br />
<do work><br />
$ bzr commit<br />
<error, someone else has changed things><br />
$ bzr update<br />
<check all is okay><br />
$ bzr commit<br />
<br />
==SVN-style checkout==<br />
<br />
Bazaar can be used very much like SVN.<br />
<br />
* Get the latest Inkscape code: <tt>bzr checkout lp:inkscape</tt><br />
* Make changes to the files. If you add new files, add them to version control with <tt>bzr add ''file''</tt>. You can recursively add all new files by writing simply <tt>bzr add</tt> in the top level directory.<br />
* Commit the changes, making them accessible to others: <tt>bzr commit</tt><br />
* Receive the most up-to-date version of the code: <tt>bzr update</tt><br />
<br />
===Differences from SVN===<br />
<br />
* Commits will fail if your checkout is not up to date, even if there would be no conflicts.<br />
* The revision number is an attribute of the working tree, not of individual files. It is not possible to have different portions of the working tree at different revisions.<br />
* <tt>bzr commit ''file''</tt> works like <tt> svn commit ''file'' && svn update ''project-root''</tt>. After a successful partial commit, the entire tree's revision is increased by 1.<br />
* No special server is needed to publish a branch. You can push branches to anywhere, including simple FTP shares. In our scenario, Launchpad works like a central repository, but it's not required to publish everything there.<br />
* You create branches locally. To simulate creating a SVN-style branch on Launchpad, you need to create a local branch, push it, then bind it to the pushed location.<br />
<br />
==Using branches==<br />
This will asumme this directory layout:<br />
inkscape<br />
+-trunk<br />
| +-doc<br />
| +-share<br />
| +-src<br />
| +-po<br />
| +-...<br />
+-my-branch<br />
+-some-other-branch<br />
<br />
===Repository setup===<br />
If you are working on several things at once, it's better to use one branch per feature. Here is how to work with branches.<br />
<br />
* Create a shared repository for your branches. This brings significant space savings if you have several branches, but is not mandatory: <tt>bzr init-repo --rich-root inkscape</tt>. This will create the directory <tt>inkscape</tt>, which will contain a shared repository used by all branches within it, in the rich root format. This is the format currently used by our Launchpad repository - if you choose another format, you might not be able to push your branches to Launchpad. Enter the directory just created: <tt>cd inkscape</tt><br />
* Create a new branch: <tt>bzr branch lp:inkscape my-branch</tt>. This will retrieve the main branch of Inkscape and put it in the subdirectory <tt>my-branch</tt>.<br />
* Make changes. Commit them locally using <tt>bzr commit</tt>. Note that this doesn't touch the trunk on Launchpad; you are only committing to your local repository.<br />
* If somebody else modified the trunk, resync with it: <tt>bzr merge</tt> (merging will automatically use the parent branch if none is specified)<br />
<br />
===Publishing branches on Launchpad===<br />
To publish branches on Launchpad, you have to add an SSH key to your account. You can generate a key using the program <tt>ssh-keygen</tt>.<br />
<br />
When you added a key to your account, you can now use the Launchpad integration features.<br />
<br />
* First you have to log in: <tt>bzr launchpad-login ''launchpad-username''</tt>. You need to use your username, not your display name.<br />
* Publish your branch on Launchpad: <tt>bzr push lp:~''launchpad-username''/inkscape/my-branch</tt>. Of course if you're working with a different project, substitute <tt>inkscape</tt> with its Launchpad name.<br />
* The push location will be saved. To update the branch on Launchpad, write <ttbzr push</tt> after your commits.<br />
* If you want to always commit directly to the remote branch on Launchpad, write <tt>bzr bind lp:~''launchpad-username''/inkscape/my-branch</tt> after the initial push. This will convert your local branch into a checkout of the remote branch.<br />
<br />
===Merging branches into trunk===<br />
<br />
Way A: commit to a checkout of the trunk. This requires a trunk checkout, but for some people is more logical.<br />
<br />
* Navigate to a checkout of the trunk.<br />
* Execute <tt>bzr merge ''branch-url''</tt>. This will modify the files to receive the changes from the specified branch but will not modify the trunk.<br />
* After verifying the changes (e.g. compile the program and see whether it doesn't crash on startup), execute <tt>bzr commit</tt> to apply the changes from the merge to the trunk.<br />
<br />
Way B: merge from trunk, then push. It doesn't require a trunk checkout, but it may be less obvious what is happening.<br />
<br />
* Navigate to the branch you want to merge.<br />
* Execute <tt>bzr merge ''trunk-location''</tt>, where ''trunk-location'' might be your local trunk checkout or <tt>lp:inkscape</tt><br />
* Verify the changes, then execute <tt>bzr commit</tt>.<br />
* Push to trunk: <tt>bzr push lp:inkscape</tt><br />
<br />
===Local branching===<br />
<br />
Naturally, all this also works locally. For example, when you're in the <tt>inkscape</tt> directory, you can write <tt>bzr branch trunk export-dialog</tt> to create a new branch of the trunk called <tt>export-dialog</tt>, where you'll work only on improving the export dialog. Similarly, you can merge between local branches.<br />
<br />
==Best Practicals for Inkscape Project==<br />
<br />
===Registering Bugfixes===<br />
<br />
Launchpad will automatically mark a bug "Fix Available" (rather than "Fix Committed") once somebody commits using the flag --fixes, e.g. (if you fix those two bugs in one commit):<br />
bzr commit --fixes lp:123456 --fixes lp:123457 -m 'patch description'<br />
Then, bugs can be changed automatically from "Fix Available" to "Fix Released"<br />
<br />
[http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/using_bazaar_with_launchpad.html#changing-the-state-in-launchpad-while-committing-in-bazaar Read more: "Changing the state in Launchpad while committing in Bazaar"]<br />
<br />
==External links==<br />
* [http://doc.bazaar-vcs.org/latest/en/ Bazaar manual]</div>Chris Morgan