> On Sep 28, 2022, at 7:10, Harald Oehlmann wrote:
>
> I will see, if I can work around it with SVN. I just told myself a fool, as I
> thought for 20 years, that this basic requirement was no problem, but it is.
I’ve used a script that would enumerate the externals and used the ‘{DATE}’
form
On Jun 5, 2020, at 8:22, Roelof Berg wrote:
>
> I will create a script named SubWCRev.sh with a content like:
>
> #!/bin/bash
> echo -n "{\""
> echo -n `svn info | grep -e "^URL: " | sed 's/URL: //g'`
> echo -n "\",\""
> echo -n `svn info | grep -e "^Revision: " | sed 's/Revision: //g'`
> echo "\
> On Nov 6, 2018, at 15:41, Bo Berglund wrote:
>
> on-recursive would work, but is it really available for svn ci?
> It is not mentioned in the svnbook
But “svn ci —help” does list it as an available option, at least on my system
running 1.9.4.
Alfred
> On Nov 6, 2018, at 15:11, Bo Berglund wrote:
>
> What should I use as argument so that only the changed files in the
> current dir are committed?
Will the -N [—non-recursive] option work for you?
Alfred
> On Thu, Jun 07, 2018 at 09:04:29AM +0200, Stefan Sperling wrote:
>> On Wed, Jun 06, 2018 at 03:12:20PM -0400, Alfred von Campe wrote:
>>> I’m trying to remove two sensitive directories from a repo so we can have a
>>> 3rd party work on it. I first dumped the en
I’m trying to remove two sensitive directories from a repo so we can have a 3rd
party work on it. I first dumped the entire repo, and now I’m trying to remove
two directories from one particular branch. But svndumpfilter keeps failing as
follows:
$ svndumpfilter exclude branches/develop/dir1
We are switching from CentOS 6 to Ubuntu 16.04 LTS on our build servers, and
I’m not having much luck starting and unlocking the gnome-keyring-daemon from
the command line on the new servers. On the exiting CentOS 6 servers, I was
able to unlock the keychain from a script using the command “ech
On Jun 6, 2017, at 16:10, Daniel Shahaf wrote:
> Yes: --with-serf=/usr
>
> You'll need to install a (sufficiently recent version of) serf-devel.
Yes, that worked even on CentOS 6 -- thanks! I was able to build the tool
and it cleaned up the svn:mergeinfo property exactly as I had expected.
I c
On Jun 6, 2017, at 13:56, Daniel Shahaf wrote:
> The runtime linker finds libsvn_gnome_keyring.so in /usr/lib, rather
> than the one in the build tree.
OK, that makes sense (I think).
> Your options include:
>
> - Link statically. (--enable-all-static to configure)
When I first tried this I w
On Jun 5, 2017, at 17:08, Daniel Shahaf wrote:
> What you need to run is:
>
> ./autogen.sh && ./configure && make svn-mergeinfo-normalizer
>
> You do need APR libraries for that. (Install the 'apr-dev' package.)
It took a while to get all dependencies sorted out on CentOS 6 (BTW, it’s
apr-deve
On Jun 5, 2017, at 14:14, Daniel Shahaf wrote:
> 'make svn-mergeinfo-normalizer' will build the tool. It can be run
> in-tree, or you can run 'make install-tools' to install it.
Hmm, I don’t see a Makefile in
^/subversion/trunk/tools/client-side/svn-mergeinfo-normalizer
or its immediate parent
Stefan:
> I'm regularly using the svn mergeinfo normalizer myself. It should suit your
> requirements quite well, but you'd be aware that it hasn't been tested
> thoroughly by a lot of people, since it's a new tool in the not yet released
> 1.10 development branch.
>
I will test out this tool.
On Jun 2, 2017, at 8:25, Nico Kadel-Garcia wrote:
> I suspect you're going to hurt yourself if you try this sort of stunt.
> Not that it might not work in theory for some cases, but it's not
> tested and is against the basic "never, never, never, and did I
> mention never alter history" approach t
On May 31, 2017, at 11:18, I wrote:
> After many years of development, we have over 100 entries in the
> svn:mergeinfo property of our trunk. I am thinking about manually editing
> the property to remove entries for all branches that have been deleted or are
> no longer used (and should be del
After many years of development, we have over 100 entries in the svn:mergeinfo
property of our trunk. I am thinking about manually editing the property to
remove entries for all branches that have been deleted or are no longer used
(and should be deleted). I am hoping that once I merge trunk i
> Cheers:
>
> Doug
>
> On Tue, Apr 11, 2017 at 9:17 AM, Alfred von Campe <mailto:alf...@von-campe.com>> wrote:
> Hi Doug:
>
> The reason is pretty simple: we develop embedded software for a 32-bit
> platform and compile for both the target (using a cross compi
one would continue to run 32-bit at this time? If you could
> help me understand
> then perhaps I can reverse that decision...
>
> Thank you.
>
> Doug
>
> On Mon, Apr 10, 2017 at 10:21 AM, Alfred von Campe <mailto:alf...@von-campe.com>> wrote:
> We are not
On Apr 7, 2017, at 20:46, Nico Kadel-Garcia wrote:
>
> On Fri, Apr 7, 2017 at 9:57 AM, Alfred von Campe wrote:
>> Does anyone on this list have a pointer to a repo that hosts the latest
>> 32-bit (i686) Subversion binaries for RHEL 6? I’ve been using the WANdisco
Does anyone on this list have a pointer to a repo that hosts the latest 32-bit
(i686) Subversion binaries for RHEL 6? I’ve been using the WANdisco SVN Repo
1.9 (http://opensource.wandisco.com/centos/6/svn-1.9/RPMS), but it only has
version 1.9.5-1 for 64-bit (x86_64). The latest 32-bit binarie
On Sep 2, 2016, at 16:22, Stefan Sperling wrote:
> If you need a specific set of property changes in your tag, you
> can create a working copy which contains the necessary changes
> and then copy this working copy to a tag.
Yes, I understand this, but...
> We cannot automate details of everybod
On Sep 2, 2016, at 4:07, Bert Huijben wrote:
>
> A single argument specifying a revision may only work for very specific
> scenarios. The --pin-externals feature also works when you have dozens of
> externals, all pointing towards different repositories.
Right, but could you consider the follo
On Jul 18, 2016, at 9:49, Andreas Stieger wrote:
> I wrote nothing of GUI.
Doh! I just saw the “UI” in capital letters and complete missed the “cli” in
lower case that preceded it - sorry about that! Anyway, I’m no closer in
resolving this merge issue, but will attempt to merge the revisions
On Jul 18, 2016, at 3:00, Andreas Stieger wrote:
> Commonly caused by explicit subtree mergeinfo. Check for svn:mergeinfo
> properties set on subtrees for both the merge source and the merge target.
Unfortunately that’s not the case here. While there was one svn:mergeinfo
property in a subtre
gt; On Jul 15, 2016, at 6:10, Alfred von Campe wrote:
>
> On Jul 15, 2016, at 3:02, Stefan Sperling wrote:
>
>> I'm afraid it's not obvious to me what issue you are referring to.
>>
>> Which behaviour are you expecting, and how does Subversion not meet
On Jul 15, 2016, at 3:02, Stefan Sperling wrote:
> I'm afraid it's not obvious to me what issue you are referring to.
>
> Which behaviour are you expecting, and how does Subversion not meet
> your expectations?
I expect Subversion to merge only revisions 29203:HEAD of branchA into
branchB. Why
A user at work came to me with a strange merge issue and I have been able to
reproduce it. This happens with both a 1.8.16 and 1.9.4 Linux CLI client. I
usually can resolve these merge issues by deleting superfluous svn:mergeinfo
properties in subdirectories and/or by editing the svn:mergeinfo
Thanks to all who have shared their respective policies. I’d be very
interested to hear from the Subversion contributors themselves as to what the
policy is for the Subversion repo.
Alfred
information in
> your Subversion repositories. You want to keep the list of people that can
> change the revprops (and the revisions themselves) to an absolute minimum.
>
> Eric.
>
>
> On Fri, Feb 26, 2016 at 10:03 AM, Alfred von Campe <mailto:alf...@von-campe.com>> w
any other revprops.
>
> Eric.
>
> On Fri, Feb 26, 2016 at 7:40 AM, Alfred von Campe <mailto:alf...@von-campe.com>> wrote:
> Is modifying the unversioned svn:log property considered bad practice? We’re
> about to upgrade to a new Subversion server at work, and the ce
Is modifying the unversioned svn:log property considered bad practice? We’re
about to upgrade to a new Subversion server at work, and the central group that
manages that server will no longer allow modifications to unversioned
properties. Their main reason is so that third party tools like Jir
On Jan 20, 2016, at 11:29, Philip Martin wrote:
> You encountered a packaging bug. WANdisco's Subversion 1.8 package for
> RHEL/CentOS 6 is going to be rebuilt to have useable python bindings.
Excellent, thanks for the update. I will wait for the next release and
then try again.
Alfred
On Jan 20, 2016, at 6:40, Philip Martin wrote:
> The Subversion Python bits have been installed in the Python 2.6 tree
> and really need to be in the Python 2.7 tree. On a CentOS 6 machine
> with Python 2.7 installed via scl I can make things work by moving the
> Python bits from the 2.6 location
On Jan 19, 2016, at 15:09, Philip Martin wrote:
> I think that means your bindings were built against python 2.7, which
> provides PyCapsule_Import, while you are trying to use 2.6, which does
> not provide it.
Thanks for the info. So how do I resolve this? I’m not a Python person,
but I do kno
On Jan 17, 2016, at 21:26, Daniel Shahaf wrote:
>
> Alfred von Campe wrote on Wed, Jan 13, 2016 at 20:54:12 -0500:
>> Is there any documentation for this script (other than the script
>> itself)?
>
> There's mailer.conf.example in the same directory.
Thanks, Daniel
)?
Alfred
> On Jan 13, 2016, at 11:52, Ryan Schmidt
> wrote:
>
>
> On Jan 13, 2016, at 9:27 AM, Alfred von Campe wrote:
>>
>> We are using a (very old) commit-email.pl script to send out email
>> notifications from a post-commit hook on our Linux server
We are using a (very old) commit-email.pl script to send out email
notifications from a post-commit hook on our Linux server running Subversion
1.7.5. Lately I’ve noticed some emails that contain lots of “unprintable”
characters. Here is a snippet from a recent commit:
If it?\226?\128?\15
Bert:
> This error can be triggered (without further details) if our serf HTTP
> library decides to cancel the request... But for that it would need a good
> reason.
>
> It would be very interesting to know what caused this... A network trace (or
> serf debug output) would be very valuable. Wh
I was going to chime in earlier, but something in Brane’s response finally put
me over the edge. We are having a very similar error when updating over VPN
(the problem does not occur when in the office):
Summary of conflicts:
Text conflicts: 1
svn: E175002: REPORT request on '/hepd/Shelby/!sv
On Feb 2, 2015, at 13:09, gangadhar jannu wrote:
>
> Is there any other alternatives rather than upgrading subversion...?
Probably not. Version 1.4 is old, actually ancient and if there was a bug in
it that causes your issue, it will never be fixed. There have been so many
improvements in 1
We recently switched from svn+ssh:// to https:// access for Subversion on our
Linux desktops, by configuring Subversion to store passwords in a secure manner
using Gnome Keyring. So far, so good. The performance increase in checkouts,
updates, logs, etc. is noticeable. However, I haven’t been
We have a repo that we want to split up into multiple repos. The strategy to
do this is fairly simple:
1. Dump repo using svnadmin dump
2. Construct a list of paths we want to exclude by greping for Node-path: in
the dump file and greping that for certain directory names to exclude
3. Use
Thanks to all for the suggestions. I actually oversimplified the situation a
little bit (this repo has multiple projects with trunk, branches, and tags
directories underneath them), which makes the script a little more complicated.
But the concepts presented so far have given me a path forward
I need to implement a post-commit hook that does the following in a "standard"
Subversion repository (with trunk, branches, and tags at the top level):
1. Checks for existence of a certain property in the top-level directory of
the trunk or branch
2. If property exists, check if any files li
On Oct 25, 2013, at 22:28, Branko Čibej wrote:
> On 25.10.2013 22:23, Alfred von Campe wrote:
>> Everything is working as expected so far. Users in each group can only
>> access their respective projects, and users in both groups can access both
>> projects. But now
We access our Subversion repositories mainly via svn+ssh:// on a central
server. We limit access to the repos using Unix group membership. For
example, the repo for ProjectA has 770 permissions and belongs to GroupA and
ProjectB also has 770 permission and belongs to GroupB. So users who are
45 matches
Mail list logo
