Skip to content

Partial update client-svn.asc #80

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
andres-mancera merged 1 commit into from
Feb 16, 2018
Merged

Partial update client-svn.asc #80

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
116 changes: 58 additions & 58 deletions book/09-git-and-other-scms/sections/client-svn.asc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,46 +1,46 @@
[[_git_svn]]
==== Git and Subversion
==== Git y Subversion

(((Subversion)))(((Interoperation with other VCSs, Subversion)))
A large fraction of open source development projects and a good number of corporate projects use Subversion to manage their source code.
It's been around for more than a decade, and for most of that time was the _de facto_ VCS choice for open-source projects.
It's also very similar in many ways to CVS, which was the big boy of the source-control world before that.
Una gran parte de los proyectos de desarrollo de código abierto y un buen número de proyectos corporativos usan Subversion para administrar sus códigos de la fuente.
Ha estado con nosotros por al rededor de una década, y la mayor de ese tiempo fue el _de facto_ VCS la opción para los proyectos de código abierto.
En algunas partes es muy similar al CVS, el que fue el preferido para las fuentes de control en todo el mundo antes de esto.

(((git commands, svn)))(((git-svn)))
One of Git's great features is a bidirectional bridge to Subversion called `git svn`.
This tool allows you to use Git as a valid client to a Subversion server, so you can use all the local features of Git and then push to a Subversion server as if you were using Subversion locally.
This means you can do local branching and merging, use the staging area, use rebasing and cherry-picking, and so on, while your collaborators continue to work in their dark and ancient ways.
It's a good way to sneak Git into the corporate environment and help your fellow developers become more efficient while you lobby to get the infrastructure changed to support Git fully.
The Subversion bridge is the gateway drug to the DVCS world.

===== `git svn`
Una de las mejores características de Git es un puente bidireccional para Subversion llamado `git svn`.
Esta herramienta te permite usar Git as como un cliente válido para el servidor de Subversion, de manera que puedes usar todas las opciones locales del Git y déspues ponerlas en el servidor de Subversion como si lo estuvieras usando localmente.
Esto significa que puede realizar bifurcaciones y fusiones locales, usar el área de preparación, usar el rebasamiento y la selección selectiva, y demás, mientras sus colaboradores continúan trabajando en formas oscuras y antiguas.
Es una buena manera de introducir a hurtadillas a Git en el entorno corporativo y ayudar a tus compañeros desarrolladores a ser más eficientes mientras presionas para que se modifique la infraestructura para que sea compatible con el Git por completo.
El puente de Subversion es la droga de entrada al mundo de DVCS.

The base command in Git for all the Subversion bridging commands is `git svn`.
It takes quite a few commands, so we'll show the most common while going through a few simple workflows.
===== `git svn`

It's important to note that when you're using `git svn`, you're interacting with Subversion, which is a system that works very differently from Git.
Although you *can* do local branching and merging, it's generally best to keep your history as linear as possible by rebasing your work, and avoiding doing things like simultaneously interacting with a Git remote repository.
El comando base en Git para todos los comandos de puente de Subversion es `git svn`.
Se requieren bastantes comandos, por lo que mostraremos los más comunes mientras realizamos algunos flujos de trabajo simples.

Don't rewrite your history and try to push again, and don't push to a parallel Git repository to collaborate with fellow Git developers at the same time.
Subversion can have only a single linear history, and confusing it is very easy.
If you're working with a team, and some are using SVN and others are using Git, make sure everyone is using the SVN server to collaborate – doing so will make your life easier.
Es importante tener en cuenta que cuando usas `git svn`, estás interactuando con Subversion, que es un sistema que funciona de manera muy diferente a Git.
Aunque * puede * realizar bifurcaciones y fusiones locales, generalmente es mejor mantener su historial lo más lineal posible al volver a basar su trabajo y evitar hacer cosas como interactuar simultáneamente con un repositorio remoto de Git.

===== Setting Up
No reescriba su historial y trate de volver a presionar, y no presione a un repositorio paralelo de Git para colaborar con otros desarrolladores de Git al mismo tiempo.
Subversion solo puede tener un único historial lineal, y confundirlo es muy fácil.
Si trabajas con un equipo, y algunos utilizan SVN y otros usan Git, asegúrate de que todos estén usando el servidor SVN para colaborar, ya que hacerlo te hará la vida más sencilla.

To demonstrate this functionality, you need a typical SVN repository that you have write access to.
If you want to copy these examples, you'll have to make a writeable copy of my test repository.
In order to do that easily, you can use a tool called `svnsync` that comes with Subversion.
For these tests, we created a new Subversion repository on Google Code that was a partial copy of the `protobuf` project, which is a tool that encodes structured data for network transmission.
===== Configurando

To follow along, you first need to create a new local Subversion repository:
Para demostrar esta funcionalidad, necesitas un repositorio SVN típico al que tengas acceso de escritura.
Si desea copiar estos ejemplos, tendrá que hacer una copia escribible de mi repositorio de prueba.
Para hacer eso fácilmente, puedes usar una herramienta llamada `svnsync` que viene con Subversion.
Para estas pruebas, creamos un nuevo repositorio de Subversion en Google Code que era una copia parcial del proyecto `protobuf`, que es una herramienta que codifica datos estructurados para la transmisión de la red.
Para seguir, primero necesitas crear un nuevo repositorio local de Subversion:

[source,console]
----
$ mkdir /tmp/test-svn
$ svnadmin create /tmp/test-svn
----

Then, enable all users to change revprops – the easy way is to add a `pre-revprop-change` script that always exits 0:
Luego, habilite a todos los usuarios para cambiar revprops - la manera más fácil es agregar un script `pre-revprop-change` que siempre sale de 0:

[source,console]
----
Expand All @@ -50,16 +50,16 @@ exit 0;
$ chmod +x /tmp/test-svn/hooks/pre-revprop-change
----

You can now sync this project to your local machine by calling `svnsync init` with the to and from repositories.
Ahora puede sincronizar este proyecto con su máquina local llamando a `svnsync init` con los repositorios

[source,console]
----
$ svnsync init file:///tmp/test-svn \
http://progit-example.googlecode.com/svn/
----

This sets up the properties to run the sync.
You can then clone the code by running
Esto configura las propiedades para ejecutar la sincronización.
A continuación, puede clonar el código ejecutando

[source,console]
----
Expand All @@ -72,14 +72,14 @@ Copied properties for revision 2.
[…]
----

Although this operation may take only a few minutes, if you try to copy the original repository to another remote repository instead of a local one, the process will take nearly an hour, even though there are fewer than 100 commits.
Subversion has to clone one revision at a time and then push it back into another repository – it's ridiculously inefficient, but it's the only easy way to do this.
Aunque esta operación puede llevar solo unos minutos, si intenta copiar el repositorio original a otro repositorio remoto en lugar de uno local, el proceso tomará casi una hora, aunque haya menos de 100 confirmaciones.
Subversion tiene que clonar una revisión a la vez y luego volver a insertarla en otro repositorio; es ridículamente ineficiente, pero es la única manera fácil de hacerlo.

===== Getting Started
===== Empezando

Now that you have a Subversion repository to which you have write access, you can go through a typical workflow.
You'll start with the `git svn clone` command, which imports an entire Subversion repository into a local Git repository.
Remember that if you're importing from a real hosted Subversion repository, you should replace the `file:///tmp/test-svn` here with the URL of your Subversion repository:
Ahora que tienes un repositorio de Subversion al que tienes acceso para escribir, puedes ir a través de un flujo de trabajo típico.
Comenzarás con el comando `git svn clone`, que importa un repositorio completo de Subversion en un repositorio local de Git.
Recuerde que si está importando desde un repositorio de Subversion alojado real, debe reemplazar el `file: /// tmp / test-svn` aquí con la URL de su repositorio de Subversion:

[source,console]
----
Expand All @@ -101,22 +101,22 @@ Checked out HEAD:
file:///tmp/test-svn/trunk r75
----

This runs the equivalent of two commands – `git svn init` followed by `git svn fetch` – on the URL you provide.
This can take a while.
The test project has only about 75 commits and the codebase isn't that big, but Git has to check out each version, one at a time, and commit it individually.
For a project with hundreds or thousands of commits, this can literally take hours or even days to finish.
Esto ejecuta el equivalente de dos comandos - `git svn init` seguido de` git svn fetch` - en la URL que proporcione.
Esto puede tomar un rato.
El proyecto de prueba solo tiene alrededor de 75 confirmaciones y la base de código no es tan grande, pero Git tiene que verificar cada versión, una a la vez, y enviarla por separado.
Para un proyecto con cientos o miles de confirmaciones, esto puede demorar literalmente horas o incluso días.

The `-T trunk -b branches -t tags` part tells Git that this Subversion repository follows the basic branching and tagging conventions.
If you name your trunk, branches, or tags differently, you can change these options.
Because this is so common, you can replace this entire part with `-s`, which means standard layout and implies all those options.
The following command is equivalent:
La parte `-T trunk -b branches -t tags` le dice a Git que este repositorio de Subversion sigue las convenciones básicas de bifurcación y etiquetado.
Si nombra el tronco, las ramas o las etiquetas de manera diferente, puede cambiar estas opciones.
Debido a que esto es tan común, puede reemplazar esta parte completa con `-s`, lo que significa diseño estándar e implica todas esas opciones.
El siguiente comando es equivalente:

[source,console]
----
$ git svn clone file:///tmp/test-svn -s
----

At this point, you should have a valid Git repository that has imported your branches and tags:
En este punto, debe tener un repositorio de Git válido que haya importado sus ramas y etiquetas:

[source,console]
----
Expand All @@ -130,9 +130,9 @@ $ git branch -a
remotes/origin/trunk
----

Note how this tool manages Subversion tags as remote refs.
Tenga en cuenta cómo esta herramienta gestiona las etiquetas de Subversion como referencias remotas.
(((git commands, show-ref)))
Let's take a closer look with the Git plumbing command `show-ref`:
Echemos un vistazo más de cerca con el comando de plomería de Git `show-ref`:

[source,console]
----
Expand All @@ -146,7 +146,7 @@ a9f074aa89e826d6f9d30808ce5ae3ffe711feda refs/remotes/origin/tags/release-2.0.2r
556a3e1e7ad1fde0a32823fc7e4d046bcfd86dae refs/remotes/origin/trunk
----

Git doesn't do this when it clones from a Git server; here's what a repository with tags looks like after a fresh clone:
Git no hace esto cuando se clona desde un servidor Git; esto es lo que parece un repositorio con etiquetas después de un nuevo clon:

[source,console]
----
Expand All @@ -159,12 +159,12 @@ c3dcbe8488c6240392e8a5d7553bbffcb0f94ef0 refs/remotes/origin/master
6dcb09b5b57875f334f61aebed695e2e4193db5e refs/tags/v1.0.0
----

Git fetches the tags directly into `refs/tags`, rather than treating them remote branches.
Git busca las etiquetas directamente en `refs / tags`, en lugar de tratarlas en sucursales remotas.

===== Committing Back to Subversion
===== Comprometerse con la subversión

Now that you have a working repository, you can do some work on the project and push your commits back upstream, using Git effectively as a SVN client.
If you edit one of the files and commit it, you have a commit that exists in Git locally that doesn't exist on the Subversion server:
Ahora que tiene un repositorio en funcionamiento, puede hacer algo de trabajo en el proyecto e impulsar sus confirmaciones en sentido ascendente, utilizando Git de manera efectiva como un cliente SVN.
Si edita uno de los archivos y lo confirma, tiene una confirmación que existe en Git localmente y que no existe en el servidor de Subversion:

[source,console]
----
Expand All @@ -173,9 +173,9 @@ $ git commit -am 'Adding git-svn instructions to the README'
1 file changed, 5 insertions(+)
----

Next, you need to push your change upstream.
Notice how this changes the way you work with Subversion – you can do several commits offline and then push them all at once to the Subversion server.
To push to a Subversion server, you run the `git svn dcommit` command:
A continuación, debe impulsar su cambio en sentido ascendente.
Observe cómo esto cambia la forma en que trabaja con Subversion: puede hacer varias confirmaciones fuera de línea y luego enviarlas todas de una vez al servidor de Subversion.
Para enviar a un servidor de Subversion, ejecute el comando `git svn dcommit`:

[source,console]
----
Expand All @@ -189,10 +189,10 @@ No changes between 4af61fd05045e07598c553167e0f31c84fd6ffe1 and refs/remotes/ori
Resetting to the latest refs/remotes/origin/trunk
----

This takes all the commits you've made on top of the Subversion server code, does a Subversion commit for each, and then rewrites your local Git commit to include a unique identifier.
This is important because it means that all the SHA-1 checksums for your commits change.
Partly for this reason, working with Git-based remote versions of your projects concurrently with a Subversion server isn't a good idea.
If you look at the last commit, you can see the new `git-svn-id` that was added:
Esto toma todas las confirmaciones que hayas realizado sobre el código del servidor de Subversion, una confirmación de Subversion para cada una, y luego reescribe tu compromiso local de Git para incluir un identificador único.
Esto es importante porque significa que todas las sumas de comprobación de SHA-1 cambian.
En parte por esta razón, trabajar con versiones remotas basadas en Git de sus proyectos simultáneamente con un servidor de Subversion no es una buena idea.
Si mira la última confirmación, puede ver el nuevo `git-svn-id` que se agregó:

[source,console]
----
Expand All @@ -206,8 +206,8 @@ Date: Thu Jul 24 03:08:36 2014 +0000
git-svn-id: file:///tmp/test-svn/trunk@77 0b684db3-b064-4277-89d1-21af03df0a68
----

Notice that the SHA-1 checksum that originally started with `4af61fd` when you committed now begins with `95e0222`.
If you want to push to both a Git server and a Subversion server, you have to push (`dcommit`) to the Subversion server first, because that action changes your commit data.
Observe que la suma de comprobación SHA-1 que originalmente comenzó con `4af61fd` cuando usted cometió ahora comienza con` 95e0222`.
Si desea enviar tanto a un servidor de Git como a un servidor de Subversion, primero tiene que presionar ('commit') al servidor de Subversion, porque esa acción cambia sus datos de confirmación.

===== Pulling in New Changes

Expand Down