ran script/content-migrations/remove-map-topics.js && script/content-migrations/update-tocs.js
This commit is contained in:
Sarah Schneider
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: Working with Subversion on GitHub
|
||||
intro: You can use Subversion clients and some Subversion workflows and properties with GitHub.
|
||||
redirect_from:
|
||||
- /articles/working-with-subversion-on-github
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
children:
|
||||
- /what-are-the-differences-between-subversion-and-git
|
||||
- /support-for-subversion-clients
|
||||
- /subversion-properties-supported-by-github
|
||||
---
|
||||
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: Subversion properties supported by GitHub
|
||||
intro: 'There are several Subversion workflows and properties that are similar to existing functionality on {% data variables.product.product_name %}.'
|
||||
redirect_from:
|
||||
- /articles/subversion-properties-supported-by-github
|
||||
- /github/importing-your-projects-to-github/subversion-properties-supported-by-github
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
---
|
||||
### Executable files (svn:executable)
|
||||
|
||||
We convert `svn:executable` properties by updating the file mode directly before adding it to the Git repository.
|
||||
|
||||
### MIME types (svn:mime-type)
|
||||
|
||||
{% data variables.product.product_name %} internally tracks the mime-type properties of files and the commits that added them.
|
||||
|
||||
### Ignoring unversioned items (svn:ignore)
|
||||
|
||||
If you've set files and directories to be ignored in Subversion, {% data variables.product.product_name %} will track them internally. Files ignored by subversion clients are completely distinct from entries in a *.gitignore* file.
|
||||
|
||||
### Currently unsupported properties
|
||||
|
||||
{% data variables.product.product_name %} doesn't currently support `svn:externals`, `svn:global-ignores`, or any properties not listed above, including custom properties.
|
||||
@@ -0,0 +1,131 @@
|
||||
---
|
||||
title: Support for Subversion clients
|
||||
intro: GitHub repositories can be accessed from both Git and Subversion (SVN) clients. This article covers using a Subversion client on GitHub and some common problems that you might run into.
|
||||
redirect_from:
|
||||
- /articles/support-for-subversion-clients
|
||||
- /github/importing-your-projects-to-github/support-for-subversion-clients
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
---
|
||||
GitHub supports Subversion clients via the HTTPS protocol. We use a Subversion bridge to communicate svn commands to GitHub.
|
||||
|
||||
### Supported Subversion features on GitHub
|
||||
|
||||
#### Checkout
|
||||
|
||||
The first thing you'll want to do is a Subversion checkout. Since Git clones keep the working directory (where you edit files) separate from the repository data, there is only one branch in the working directory at a time.
|
||||
|
||||
Subversion checkouts are different: they mix the repository data in the working directories, so there is a working directory for each branch and tag you've checked out. For repositories with many branches and tags, checking out everything can be a bandwidth burden, so you should start with a partial checkout.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.copy-clone-url %}
|
||||
|
||||
3. Make an empty checkout of the repository:
|
||||
```shell
|
||||
$ svn co --depth empty https://github.com/<em>user</em>/<em>repo</em>
|
||||
> Checked out revision 1.
|
||||
$ cd <em>repo</em>
|
||||
```
|
||||
|
||||
4. Get the `trunk` branch. The Subversion bridge maps trunk to the Git HEAD branch.
|
||||
```shell
|
||||
$ svn up trunk
|
||||
> A trunk
|
||||
> A trunk/README.md
|
||||
> A trunk/gizmo.rb
|
||||
> Updated to revision 1.
|
||||
```
|
||||
|
||||
5. Get an empty checkout of the `branches` directory. This is where all of the non-`HEAD` branches live, and where you'll be making feature branches.
|
||||
```shell
|
||||
$ svn up --depth empty branches
|
||||
Updated to revision 1.
|
||||
```
|
||||
|
||||
#### Creating branches
|
||||
|
||||
You can also create branches using the Subversion bridge to GitHub.
|
||||
|
||||
From your svn client, make sure the default branch is current by updating `trunk`:
|
||||
```shell
|
||||
$ svn up trunk
|
||||
> At revision 1.
|
||||
```
|
||||
|
||||
Next, you can use `svn copy` to create a new branch:
|
||||
```shell
|
||||
$ svn copy trunk branches/more_awesome
|
||||
> A branches/more_awesome
|
||||
$ svn commit -m 'Added more_awesome topic branch'
|
||||
> Adding branches/more_awesome
|
||||
|
||||
> Committed revision 2.
|
||||
```
|
||||
|
||||
You can confirm that the new branch exists in the repository's branch dropdown:
|
||||
|
||||
|
||||
|
||||
You can also confirm the new branch via the command line:
|
||||
|
||||
```shell
|
||||
$ git fetch
|
||||
> From https://github.com/<em>user</em>/<em>repo</em>/
|
||||
> * [new branch] more_awesome -> origin/more_awesome
|
||||
```
|
||||
|
||||
#### Making commits to Subversion
|
||||
|
||||
After you've added some features and fixed some bugs, you'll want to commit those
|
||||
changes to GitHub. This works just like the Subversion you're used to. Edit your files, and use `svn commit` to record your changes:
|
||||
|
||||
```shell
|
||||
$ svn status
|
||||
> M gizmo.rb
|
||||
$ svn commit -m 'Guard against known problems'
|
||||
> Sending more_awesome/gizmo.rb
|
||||
> Transmitting file data .
|
||||
> Committed revision 3.
|
||||
$ svn status
|
||||
> ? test
|
||||
$ svn add test
|
||||
> A test
|
||||
> A test/gizmo_test.rb
|
||||
$ svn commit -m 'Test coverage for problems'
|
||||
> Adding more_awesome/test
|
||||
> Adding more_awesome/test/gizmo_test.rb
|
||||
> Transmitting file data .
|
||||
> Committed revision 4.
|
||||
```
|
||||
|
||||
#### Switching between branches
|
||||
|
||||
To switch between branches, you'll probably want to start with a checkout of `trunk`:
|
||||
|
||||
```shell
|
||||
$ svn co --depth empty https://github.com/<em>user</em>/<em>repo</em>/trunk
|
||||
```
|
||||
|
||||
Then, you can switch to another branch:
|
||||
|
||||
```shell
|
||||
$ svn switch https://github.com/<em>user</em>/<em>repo</em>/branches/more_awesome
|
||||
```
|
||||
|
||||
### Finding the Git commit SHA for a Subversion commit
|
||||
|
||||
GitHub's Subversion server exposes the Git commit sha for each Subversion commit.
|
||||
|
||||
To see the commit SHA, you should ask for the `git-commit` unversioned remote property.
|
||||
|
||||
```shell
|
||||
$ svn propget git-commit --revprop -r HEAD https://github.com/<em>user</em>/<em>repo</em>
|
||||
05fcc584ed53d7b0c92e116cb7e64d198b13c4e3
|
||||
```
|
||||
|
||||
With this commit SHA, you can, for example, look up the corresponding Git commit on GitHub.
|
||||
|
||||
### Further reading
|
||||
|
||||
* "[Subversion properties supported by GitHub](/articles/subversion-properties-supported-by-github)"
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
title: What are the differences between Subversion and Git?
|
||||
intro: 'Subversion (SVN) repositories are similar to Git repositories, but there are several differences when it comes to the architecture of your projects.'
|
||||
redirect_from:
|
||||
- /articles/what-are-the-differences-between-svn-and-git/
|
||||
- /articles/what-are-the-differences-between-subversion-and-git
|
||||
- /github/importing-your-projects-to-github/what-are-the-differences-between-subversion-and-git
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
---
|
||||
### Directory structure
|
||||
|
||||
Each *reference*, or labeled snapshot of a commit, in a project is organized within specific subdirectories, such as `trunk`, `branches`, and `tags`. For example, an SVN project with two features under development might look like this:
|
||||
|
||||
sample_project/trunk/README.md
|
||||
sample_project/trunk/lib/widget.rb
|
||||
sample_project/branches/new_feature/README.md
|
||||
sample_project/branches/new_feature/lib/widget.rb
|
||||
sample_project/branches/another_new_feature/README.md
|
||||
sample_project/branches/another_new_feature/lib/widget.rb
|
||||
|
||||
An SVN workflow looks like this:
|
||||
|
||||
* The `trunk` directory represents the latest stable release of a project.
|
||||
* Active feature work is developed within subdirectories under `branches`.
|
||||
* When a feature is finished, the feature directory is merged into `trunk` and removed.
|
||||
|
||||
Git projects are also stored within a single directory. However, Git obscures the details of its references by storing them in a special *.git* directory. For example, a Git project with two features under development might look like this:
|
||||
|
||||
sample_project/.git
|
||||
sample_project/README.md
|
||||
sample_project/lib/widget.rb
|
||||
|
||||
A Git workflow looks like this:
|
||||
|
||||
* A Git repository stores the full history of all of its branches and tags within the *.git* directory.
|
||||
* The latest stable release is contained within the default branch.
|
||||
* Active feature work is developed in separate branches.
|
||||
* When a feature is finished, the feature branch is merged into the default branch and deleted.
|
||||
|
||||
Unlike SVN, with Git the directory structure remains the same, but the contents of the files change based on your branch.
|
||||
|
||||
### Including subprojects
|
||||
|
||||
A *subproject* is a project that's developed and managed somewhere outside of your main project. You typically import a subproject to add some functionality to your project without needing to maintain the code yourself. Whenever the subproject is updated, you can synchronize it with your project to ensure that everything is up-to-date.
|
||||
|
||||
In SVN, a subproject is called an *SVN external*. In Git, it's called a *Git submodule*. Although conceptually similar, Git submodules are not kept up-to-date automatically; you must explicitly ask for a new version to be brought into your project.
|
||||
|
||||
For more information, see “[Git Tools Submodules](https://git-scm.com/book/en/Git-Tools-Submodules)" in the Git documentation.
|
||||
|
||||
### Preserving history
|
||||
|
||||
SVN is configured to assume that the history of a project never changes. Git allows you to modify previous commits and changes using tools like [`git rebase`](/github/getting-started-with-github/about-git-rebase).
|
||||
|
||||
{% tip %}
|
||||
|
||||
[GitHub supports Subversion clients](/articles/support-for-subversion-clients), which may produce some unexpected results if you're using both Git and SVN on the same project. If you've manipulated Git's commit history, those same commits will always remain within SVN's history. If you accidentally committed some sensitive data, we have [an article that will help you remove it from Git's history](/articles/removing-sensitive-data-from-a-repository).
|
||||
|
||||
{% endtip %}
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[Subversion properties supported by GitHub](/articles/subversion-properties-supported-by-github)"
|
||||
- ["Branching and Merging" from the _Git SCM_ book](https://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging)
|
||||
- "[Importing source code to GitHub](/articles/importing-source-code-to-github)"
|
||||
- "[Source code migration tools](/articles/source-code-migration-tools)"
|
||||
Reference in New Issue
Block a user