Difference between revisions of "WesnothRepository"

From The Battle for Wesnoth Wiki
(Merge in most of the material fromm the SVN page)
(We've switched to git.)
Line 5: Line 5:
 
When a release is planned, the current set of the files in the repository is frozen, given a release number, and shipped out to the world at large. Then, as files continue to be edited by the developers, the repository code advances past that point. The repository (or "repo") version is by definition the most up-to-date version of the code.
 
When a release is planned, the current set of the files in the repository is frozen, given a release number, and shipped out to the world at large. Then, as files continue to be edited by the developers, the repository code advances past that point. The repository (or "repo") version is by definition the most up-to-date version of the code.
  
Wesnoth is in the process of moving to the git version-control system and changing hosting sites.  The repository is currently at http://gna.org and the version-control system is Subversion, but we expect to move to SourceForge soon.
+
The Wesnoth repository uses Git and lives at https://sourceforge.net/p/wesnoth/code
  
==  SVN ==
+
==  Git ==
  
Wesnoth development currently (but not for much longer) is using the open-source Subversion software tool to keep developers in sync with each other. See the [http://svnbook.org SVN book] for more on how to use Subversion.  
+
Git is the most widely used open-source version-control system. You can learn more about it at the Git home page, http://git-scm.com/.
  
Subversion replaced an older program called "CVS" or "concurrent versioning system." The very earliest versions of Wesnoth were developed under CVS, and it has left a few traces far back in the version history.
+
Git replaced Subversion as Wesnoth's version control system in March 2013. Subversion had itself previously replaced an older program called "CVS" or "concurrent versioning system" in 2005. These earlier systems have left a few traces in the version history which you might encounter; some older documentation and a few files refer to them.
  
 
==  Browse the code  ==
 
==  Browse the code  ==
Line 17: Line 17:
 
There are currently two main streams of development: trunk (1.11.x) and stable branch (1.10.x). Most other branches are only used for a short time to do some testing without disturbing the main development. You can use your web browser to navigate through the source code:
 
There are currently two main streams of development: trunk (1.11.x) and stable branch (1.10.x). Most other branches are only used for a short time to do some testing without disturbing the main development. You can use your web browser to navigate through the source code:
  
http://svn.gna.org/viewcvs/wesnoth/
+
https://sourceforge.net/p/wesnoth/code
  
 
==  Download  ==
 
==  Download  ==
  
To check out trunk into a directory called ''wesnoth'' (about 400 MB to download as of March 30th 2009, and about 1.3 GB disk space required, including .svn dirs, as of June 17th 2012):
+
To check out a read-only copy into a directory called ''wesnoth-code'',
svn co http://svn.gna.org/svn/wesnoth/trunk wesnoth
 
  
Or, to check out the 1.10 branch (about 400 MB to download and 960 MB to store on disk as of March 30th 2009; by extrapolation, probably around 1.3 GB too by June 17th 2012) into a directory called ''wesnoth-1.10'':
+
  git clone git://git.code.sf.net/p/wesnoth/code wesnoth-code
  svn co http://svn.gna.org/svn/wesnoth/branches/1.10 wesnoth-1.10
 
  
More info on the repository: https://gna.org/svn/?group=wesnoth
+
==  Commit access  ==
  
==  Commit access  ==
+
For commit access, you must have a developer account on SourceForge, it must be registered as part of the Wesnoth group, and you must check out with
 +
 
 +
  git clone ssh://USER@git.code.sf.net/p/wesnoth/code wesnoth-code
  
For commit access, you must have a developer account on gna, it must be registered as part of the Wesnoth group, and you must check out with
+
where USER is your SourceForge developer name.
svn co svn+ssh://gna_username@svn.gna.org/svn/wesnoth/trunk wesnoth
 
  
 
==  Update  ==
 
==  Update  ==
  
Do this from inside the ''wesnoth'' or ''wesnoth-1.10'' directory where you checked out the repository:
+
Do this from inside the ''wesnoth-code'' directory  
  svn update
+
 
 +
  git pull
  
 
== Reviewing your changes ==
 
== Reviewing your changes ==
  
 
Before committing, it's always wise to run
 
Before committing, it's always wise to run
  svn diff
+
 
 +
  git diff
  
 
and look at the output. Some kinds of mistakes that are hard to see embedded in all the code you have modified are more easily spotted in the isolated diff lines.
 
and look at the output. Some kinds of mistakes that are hard to see embedded in all the code you have modified are more easily spotted in the isolated diff lines.
Line 48: Line 49:
 
== Generating patches ==
 
== Generating patches ==
  
Under Subversion on a Unix-like operating system, do
+
Under Subversion on a Unix-like operating system, you'll typically do
   svn diff >my.patch
+
 
 +
   git format-patch HEAD~1..HEAD
  
or something similar. If you are using git-svn a git diff is acceptable.  See [[PatchSubmissionGuidelines]] for more on how to get these merged into the public repository.
+
or something similar; "HEAD~1" may be replaced by a hash or symbolic reference to any earlier revision. This will produce one or more patch files, numbered and endingth with the extension ".patch".  See [[PatchSubmissionGuidelines]] for more on how to get these merged into the public repository.
  
 
== See Also ==
 
== See Also ==
  
 
* [[CompilingWesnoth]]
 
* [[CompilingWesnoth]]
* [[SVN_on_Windows]]
 
* [[GIT-SVN]] - for git users
 
  
 
[[Category:Development]]
 
[[Category:Development]]

Revision as of 05:12, 27 March 2013

[edit]Compiling Wesnoth

Platforms

The Battle for Wesnoth code base is stored in a version control repository. Version control allows the entire dev team to edit files concurrently. The software tracks revisions, stores a record of all edits, revents simultaneous editing from causing clashes. All changes are stored in the subversion repository.

When a release is planned, the current set of the files in the repository is frozen, given a release number, and shipped out to the world at large. Then, as files continue to be edited by the developers, the repository code advances past that point. The repository (or "repo") version is by definition the most up-to-date version of the code.

The Wesnoth repository uses Git and lives at https://sourceforge.net/p/wesnoth/code

Git

Git is the most widely used open-source version-control system. You can learn more about it at the Git home page, http://git-scm.com/.

Git replaced Subversion as Wesnoth's version control system in March 2013. Subversion had itself previously replaced an older program called "CVS" or "concurrent versioning system" in 2005. These earlier systems have left a few traces in the version history which you might encounter; some older documentation and a few files refer to them.

Browse the code

There are currently two main streams of development: trunk (1.11.x) and stable branch (1.10.x). Most other branches are only used for a short time to do some testing without disturbing the main development. You can use your web browser to navigate through the source code:

https://sourceforge.net/p/wesnoth/code

Download

To check out a read-only copy into a directory called wesnoth-code,

git clone git://git.code.sf.net/p/wesnoth/code wesnoth-code

Commit access

For commit access, you must have a developer account on SourceForge, it must be registered as part of the Wesnoth group, and you must check out with

git clone ssh://USER@git.code.sf.net/p/wesnoth/code wesnoth-code

where USER is your SourceForge developer name.

Update

Do this from inside the wesnoth-code directory

git pull

Reviewing your changes

Before committing, it's always wise to run

git diff

and look at the output. Some kinds of mistakes that are hard to see embedded in all the code you have modified are more easily spotted in the isolated diff lines.

Generating patches

Under Subversion on a Unix-like operating system, you'll typically do

 git format-patch HEAD~1..HEAD

or something similar; "HEAD~1" may be replaced by a hash or symbolic reference to any earlier revision. This will produce one or more patch files, numbered and endingth with the extension ".patch". See PatchSubmissionGuidelines for more on how to get these merged into the public repository.

See Also