Don't forget that svnadmin dump/load and svnsync don't preserve hook scripts or
other ancillary data that might be in your repository directory on the server,
so if you have hook scripts, authorization rules or other customizations, carry
those over to the new server manually. And of course any
>> Does anyone know how long it would take to export the repository of this
>> size? This will give us an estimate how long to schedule down time and cut
>> off time.
Svnsync is the easy option.
If you insist on doing a dump/load, then a) you can time a test run of a
dump/load, and b) "svnadm
On 7/25/2017 11:00 AM, Andy So wrote:
We have an old subversion /version 1.4.3 (r23084) /running on Solaris.
We would like to upgrade to use new hardware on Linux based OS (CentOS
6.9), possibly version 1.8.x or 1.9.x
Our plan is to installed and configure the latest SVN on CentOS 6.9.
Then
It’s been awhile, but isn’t changing the commit message (after a push)
potentially problematic in git?
On Tue, Jul 25, 2017 at 2:00 PM, Andy So wrote:
> We have an old subversion *version 1.4.3 (r23084) *running on Solaris.
>
> We would like to upgrade to use new hardware on Linux based OS (CentOS
> 6.9), possibly version 1.8.x or 1.9.x
>
>
>
> Our plan is to installed and configure the latest SVN
We have an old subversion version 1.4.3 (r23084) running on Solaris.
We would like to upgrade to use new hardware on Linux based OS (CentOS 6.9),
possibly version 1.8.x or 1.9.x
Our plan is to installed and configure the latest SVN on CentOS 6.9. Then go
through dump and load of the repository a
On Tue, Jul 25, 2017 at 2:48 AM, Andreas Krey wrote:
> On Thu, 20 Jul 2017 17:38:38 +, Nathan Hartman wrote:
> ...
> > Is that such a big deal?
>
> The big deal is a slightly different point. Making commit 'offline'
> not only allows me to make commits while in the middle of nowhere
> (and he
On Tue, Jul 25, 2017 at 01:59:29PM +0200, Johan Corveleyn wrote:
> It even has internal libraries with stable API's that
> allow writing plugins and GUI's on top rather than them having to drive a
> command line utility.
This is something git developers who I know personally *really want*.
Unfortu
Op 25 jul. 2017 9:48 a.m. schreef "Andreas Krey" :
On Thu, 20 Jul 2017 17:38:38 +, Nathan Hartman wrote:
...
> Subversion is a very good system. It doesn't get the credit it deserves,
Please. git managed to be faster in providing actually working
(i.e. tracked) merges than subversion, and th
On Tue, Jul 25, 2017 at 08:48:07AM +0200, Andreas Krey wrote:
> This also means that I can't maintain a patched version of
> svn (or anything in an svn repo) without having commit
> privilege to the source repo
This is obviously true, and a reason for why the Subversion project
itself has a very r
10 matches
Mail list logo
