Re: version control model of Subversion source code
* wuzhouhui: > As far as I know, new code is committed to trunk firstly, then > cherry-picked to release-branch in necessary [...] And tags are > always created on release-branch. It can be done this way, but that's not a requirement. One can also tag 'trunk', or any other branch. -Ralph
Re: How to open specified inside .svn
* wuzhouhui: > Could someone remind me that which function can be used to open > .svn/Adir/Afile in client? I'm not sure I understand what you are trying to achieve? The .svn directories (and contents) should not be accessed directly. That's what the SVN client is for. -Ralph
Re: Issues
On 24.05.18 12:46, Navod Anushan wrote: > [Junk] Can the mailing list administrators please change the configuration so that nobody can send 5-MB-photos to this list? Thank you. -Ralph
Re: Reverting accidental permanent acceptance of SSL certificate?
On 11.02.2018 16:38, Bo Berglund wrote: > Is there a client svn command to un-accept a certificate? It is easy to manually remove data from the "auth" directory, see http://svnbook.red-bean.com/en/1.8/svn.serverconfig.netmodel.html -Ralph
Re: Apache svn - how to customize rendering?
On 10.12.2017 09:30, Bo Berglund wrote: > Is there some way to enhance/customize it a bit so it gets a more > attractive look? I use the SVNIndexXSLT option to point Apache to an XSL stylesheet. -Ralph
Re: svn status does not detect a modification if the same file was touched
On 19.10.17 18:17, Daniel Shahaf wrote: > Subversion doesn't use checksums to detect modifications. 'svn status' > is based on filesize + mtime only. I seemed to remember subversion behaved like git in this regard, using a checksum (as shown in 'svn info') as an indicator, rather than raw file size. Oh well, I'm pretty sure you know first-hand how it works. ;-) -Ralph
Re: svn status does not detect a modification if the same file was touched
On 19.10.2017 12:16, Sasikala Kottegoda wrote: > In this scenario, svn status does not show anything. Also, the file > does not get commited when I issue an 'svn commit'. Is there a reason > for that? Subversion uses a hash of the file content to determine if it has been modified. Changing the modification date in the working copy, as you did with 'touch', does not alter the content, hence the file is considered unchanged. This is deliberate. -Ralph
Re: Subversion Server Replacement Query
> Hi Subversion Support, Funny way to put it. ;-) This is a public mailing list of (mostly) volunteers. > Please advise as we need to move subversion from old server with OS > RH5U3 to RH7U3, all of our repositories are hosted on NFS share. Don't use network based file systems. Really, don't. > Plan is to rsync old shared area hosting repositories to new shared > area and copy configuration files to the same path on new server. > [...] > do we have to use dump and load as that will take lots of time, due > to history and size of repositories. Set up the new server as a mirror (with local data store, in new format, not yet accessible to your users) of the existing server, use svnsync to replicate the data, over hours or days if necessary. It does not matter how long it takes to sync, since the existing server can continue to operate, and you can synchronise in portions if required. From the docs: Also noteworthy is that svnsync performs careful bookkeeping that allows it to be safely interrupted and restarted without ruining the integrity of the mirrored data. Once you are ready to switch, close user access to the old server, run svnsync one final time, change DNS names, and have the new server accept user connections. > Do users need to create a new working copies? That is a necessity whenever the repository UUID changes. -Ralph
Re: [Linux] Hook hashbang hardships
On 27.09.2016 12:59, Dario Niedermann wrote: > I found out that the issue was in the script's shebang: > > #!/bin/bash -e > > which wouldn't work. Had to remove ' -e'. Is this expected behaviour or > is there something wrong with svn (version 1.9.4 (r1740329) on > Linux/x86_64) ? Why would anything be wrong with Subversion? Apparently something is not going as expected in your own script, causing bash to exit. Scripts always have to be adapted to local needs. On some systems, the path for bash might be different, or bash might not be available at all. That's each user's own responsibility. -Ralph
Re: Planned release date for mod_dav_svn compile error fix (SVN 1.7/Apache 2.4)
On 15.05.12 09:56, Daniel Shahaf wrote: 1.7.5 will include this fix. That's good news, thanks. -Ralph
Planned release date for mod_dav_svn compile error fix (SVN 1.7/Apache 2.4)
Hi list, in February, Mario Brandt started a thread about a compile error against Apache 2.4.x (see http://svn.haxx.se/dev/archive-2012-02/0486.shtml). subversion/mod_dav_svn/util.c: In function 'dav_svn__log_err': subversion/mod_dav_svn/util.c:630:20: error: 'dav_error' has no member named 'save_errno' subversion/mod_dav_svn/util.c:631:28: error: 'dav_error' has no member named 'save_errno' A patch was suggested and discussed with Daniel Shahaf. As far as I can tell from the mailing list archives, no release date has been named for the fix, or have I overlooked something? -Ralph
Re: Mailing lists? Really?
On 28.07.10 20:13, Ds Jstc wrote: my inbox is entirely full enough, thank you. There are numerous fine MUAs out there which will gladly sort your incoming mail and prevent inbox clutter by providing folders. You might also be able to use Sieve for a server-side solution. Please change over to a threaded forum, so I can participate without resorting to email. Mailing lists are superior to forums because all relevant information is delivered without user interaction, while forums must be actively visited. Besides, forum software widely varies in usability, while each user can freely choose his personal favourite e-mail client. Also, mail can be stored locally and is available offline, if the need arises. Is this something Tigris can change? I hope Tigris will never consider abandoning mailing lists for a forum. -Ralph
