A
A
Alexey2015-02-16 09:50:00
subversion
Alexey, 2015-02-16 09:50:00

How can two SVN repositories of the same projects be kept in sync?

Good day!
The situation is as follows: there are two offices located in different cities. Programmers from both offices are working on the same big project (on different parts of it). Both have local SVN repositories. For certain reasons, otherwise it is impossible to do otherwise, everyone should have their own SVN repository (from each office it is possible to connect via rdp to the machines of another office). The problem is this: every 1-2 weeks you have to travel to another city (fortunately located nearby) and merge your changes into their repository, and them into ours. Is there any way to automate this process? Without trips to another city :)

Answer the question

In order to leave comments, you need to log in

2 answer(s)
V
Vapaamies, 2015-02-16
@Renzo

I see two solutions.
The first option is to have a meta-repository that stores links to both parts in the svn:external property . On each update from the meta-repository, it will make a nested request to update the corresponding part. Of course, you will have to commit changes to the repository of your part, and download updates for the assembly from the meta-repository.
This method requires both parts to be online, otherwise the svn:external update will hang until the timeout expires.
The second way I wanted to recommend using svnsync, but I did not understand from the help whether partial mirroring can be done. I myself use only full mirroring, so I can’t tell you more precisely.
If partial mirroring is not possible or does not work the way you want, you can extend the first method using svnsync: create a full mirror in both branches and set svn:external on it already. Then online accessibility is not required, it will be possible to synchronize as convenient. The costs of "writing to one place" -- "downloading to build from another" will remain.

I
index0h, 2015-02-16
@index0h

Well, since it’s not the intended use of a centralized VCS, as a distributed one is justified ...
What prevents you from merging the latest edits from the remote to the local machine -> pointing to your repository -> merging the latest state of the files back -> commit?
If only rdp gives access - what's the problem then? Open some ftp thread back to your machine, upload the project archive there, then merge from there for the reverse merge.
Better convince management that eating a cactus is bad (the first line of my answer). Either use centralized vcs for their intended purpose, or use decentralized ones.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question