Please publish unsubscribe information in the patch update mailings.

[CCD Systems Help Desk]

We no longer require updates for SubVersion, please remove us from the
mailing list.

 

Daniel Bragg

Senior Developer

CCD Health Systems

supp...@ccdsystems.com

 

[ANNOUNCE] Apache Subversion 1.10.0-alpha3 released

[Daniel Shahaf]

I'm happy to announce the release of Apache Subversion 1.10.0-alpha3.
Please choose the mirror closest to you by visiting:

http://subversion.apache.org/download.cgi#pre-releases

The SHA1 checksums are:

26522a1fa708ecaa9684b41065db8d6a02dbc098 subversion-1.10.0-alpha3.tar.gz
d39ac7b98b5aa8a0e868b7ebda2f73f07817f933 subversion-1.10.0-alpha3.zip
0967ff292490d6643d3f94290d4d822fde9b6a36 subversion-1.10.0-alpha3.tar.bz2

SHA-512 checksums are available at:


https://www.apache.org/dist/subversion/subversion-1.10.0-alpha3.tar.bz2.sha512

https://www.apache.org/dist/subversion/subversion-1.10.0-alpha3.tar.gz.sha512
https://www.apache.org/dist/subversion/subversion-1.10.0-alpha3.zip.sha512

PGP Signatures are available at:

http://www.apache.org/dist/subversion/subversion-1.10.0-alpha3.tar.bz2.asc
http://www.apache.org/dist/subversion/subversion-1.10.0-alpha3.tar.gz.asc
http://www.apache.org/dist/subversion/subversion-1.10.0-alpha3.zip.asc

For this release, the following people have provided PGP signatures:

   Bert Huijben [4096R/C4A6C625CCC8E1DF] with fingerprint:
3D1D C66D 6D2E 0B90 3952  8138 C4A6 C625 CCC8 E1DF
   Branko Čibej [4096R/1BCA6586A347943F] with fingerprint:
BA3C 15B1 337C F0FB 222B  D41A 1BCA 6586 A347 943F
   Stefan Sperling [2048R/4F7DBAA99A59B973] with fingerprint:
8BC4 DAE0 C5A4 D65F 4044  0107 4F7D BAA9 9A59 B973
   Daniel Shahaf [3072R/A5FEEE3AC7937444] with fingerprint:
E966 46BE 08C0 AF0A A0F9  0788 A5FE EE3A C793 7444
   Stefan Fuhrmann [4096R/99EC741B57921ACC] with fingerprint:
056F 8016 D9B8 7B1B DE41  7467 99EC 741B 5792 1ACC

This is a pre-release for what will eventually become version 1.10.0 of the
Apache Subversion open source version control system.  It may contain known
issues, a complete list of 1.10.0-blocking issues can be found
here:


https://issues.apache.org/jira/browse/SVN-4629?jql=project%20%3D%20SVN%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.10.0%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

A pre-release means the Subversion developers feel that this release
is ready for widespread testing by the community.  There are known issues
(and unknown ones!), so please use it at your own risk, though we do
encourage people to test this release thoroughly.  Of particular note, please
remember than persistent data, such as the working copy or repository
formats may change before the final release, and there may not be an
upgrade path from the pre-releases to the final.

As a note to operating system distro packagers: while we wish to have this
release candidate widely tested, we do not feel that it is ready for packaging
and providing to end-users through a distro package system.  Packaging a
release candidate poses many problems, the biggest being that our policy lets
us break compatibility between the release candidate and the final release, if
we find something serious enough.  Having many users depending on a release
candidate through their distro would cause no end of pain and frustration that
we do not want to have to deal with.  However, if your distro has a branch that
is clearly labeled as containing experimental and often broken software, and
explicitly destined to consenting developers and integrators only, then we're
okay with packaging the release candidate there.  Just don't let it near the
end users please.


Release notes for the 1.10.x release series may be found at:

http://subversion.apache.org/docs/release-notes/1.10.html

You can find the list of changes between 1.10.0-alpha3 and earlier versions at:

http://svn.apache.org/repos/asf/subversion/tags/1.10.0-alpha3/CHANGES

Questions, comments, and bug reports to users@subversion.apache.org.

Thanks,
- The Subversion Team

RE: svn vs. git

[Andreas Tscharner]

> Subject: RE: svn vs. git
>
> It’s been awhile, but isn’t changing the commit message (after a push)
> potentially problematic in git?
>

Depends on whether or not you have already pushed. You can do it easily in both 
cases, but if you have already pushed, you should not do it, otherwise you 
cause problems for everyone else...

The main reason we changed from SVN to git were the merge problems we've had 
with SVN.

Freundliche Grüsse / Best Regards

Andreas Tscharner
Entwickler / Developer

Phone: +41 81 257 07 47
E-Mail: andreas.tschar...@wenzel-metromec.ch

WENZEL Metromec AG
Rheinfelsstrasse 1
CH-7007 Chur / Switzerland
Phone: +41 81 257 07 00
www.wenzel-metromec.ch
www.wenzel-group.com






Diese Nachricht kann vertrauliche Informationen enthalten und ist 
ausschliesslich für die genannte Person bestimmt. Falls Sie nicht der 
beabsichtigte Empfänger sind, sollten Sie diese E-Mail nicht weiterleiten, 
kopieren oder in sonstiger Weise verwenden. Falls Sie diese E-Mail 
versehentlich erhalten haben, teilen Sie dies bitte umgehend dem Sender mit und 
löschen Sie diese Nachricht. Vielen Dank!

This message may contain confidential information and is intended only for the 
individual named herein. If you are not the addressee you should not 
distribute, copy or otherwise make use of this e-mail. If you have received 
this e-mail by mistake please notify the sender immediately and delete this 
message. Thank you!




Body.rtf
Description: Binary data

Re: svn vs. git

[Nico Kadel-Garcia]

On Tue, Jul 25, 2017 at 4:30 PM, Andrew Reedick  wrote:
> It’s been awhile, but isn’t changing the commit message (after a push)
> potentially problematic in git?

Yeah. It can get nasty. The "push --force" option is available, but
that's basically changing the history on what might be a central
repository, and it's the sort of operation that makes believers in
"thou shalt not touch the history" approach to source control very,
very upset. resolving discrepancies on previously synced copies of
that central repository can get nasty if you pull that sort of stunt.

The more common option is to edit the comments on the commit you *just
made locally*. It can be handy to set the date, the problem ticket
number, or to mention an additional change before making the push. And
it's especially handy to reset the "author" of a commit, because a
local commit is normally attributed to the local user on the local
host. If you're logged in as the "root" or "apache" user, to modify a
local configuration repository, it's useful to reset the "author" to
yourself before doing the push.

Resetting the "author" of a commit introduces additional dangers: for
Subversion, the "commit" is credited to the user connecting to the
Subversion server. For git, it can be reset locally, and people can
*lie* about who did the specific commit.

Re: upgrading server

[Nico Kadel-Garcia]

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

If you're bumping Subversion release to 1.8.x or 1.9.x, I'd urge you
to go to CentOS 7, which at least starts with Subverison 1.7, and get
the latest RPM's from Wandisco.

> Our plan is to installed and configure the latest SVN on CentOS 6.9. Then go
> through dump and load of the repository as described in various online post
> and documentations.  The repository is quite large…guessing the size to be
> in the order of 20-40GB

See above. Installing the latest Subversion on CentOS 6 gets into some
fairly awkward library dependencies, especially for the "serf"
libraries which are notably out of date on CentOS 6.

> Before we start undertaking such tasks
>
> 1.  Does anyone know if there are there any problem/gotcha in migrating
> the repository?
>
> 2.  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.

Definitely use svnsync, if possible, so you have no downtime and can
write-lock the original repository and do a DNS based switchover.
Rollback, if there are *any* mismatched writes to the new repository,
means starting over with all working copies, which can be quite
painful.

> Thanks for any insight.

You might consider less of an extreme version update. The more
versions you update between, I've noted more likelihood of
incompatible workflows such as the changes in the "svn:external"
formats.