-Original Message-
From: Andreas Krey [mailto:a.k...@gmx.de]
Sent: 04 June 2014 17:11
To: James French
Cc: Nico Kadel-Garcia; Andreas Stieger; users@subversion.apache.org
Subject: Re: Set a repository never ignore files
On Wed, 04 Jun 2014 15:50:35 +, James French wrote:
...
>
en only finding out later.
Oh well.
-Original Message-
From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
Sent: 04 June 2014 03:44
To: Andreas Stieger
Cc: James French; users@subversion.apache.org
Subject: Re: Set a repository never ignore files
On Tue, Jun 3, 2014 at 8:05 PM, Andreas
Morning,
I have a repo where I want to force .a files to always get added (ie not
ignored), irrespective of any ignore settings in user config files. I am happy
to set the repo to not ignore any file, if that is easier. I guess I'm after an
svn:global-no-ignore property...
Using svn 1.8.9.
Ch
Thanks for confirming that Bert. I'd prefer to keep the trunk stable so I've
recommended the reverse merge approach.
From: Bert Huijben [mailto:b...@qqmail.nl]
Sent: 25 February 2014 10:38
To: James French; users@subversion.apache.org
Subject: RE: separating out unwanted changes
T
Hi,
I wonder if someone could give me some advice on the following situation. Its
probably pretty simple but my svn knowledge has dropped off a bit. An unstable
dev branch was reintegrated and then a bunch of subsequent fixes were made on
the mainline, mixed in with other development. Stability
Thanks for the explanation Stefan. Glad svn is working properly :-)
-Original Message-
From: Stefan Sperling [mailto:s...@elego.de]
Sent: 09 September 2013 15:55
To: James French
Cc: users@subversion.apache.org
Subject: Re: Reverse merge with 1.8.3 yielded tree conflicts
On Mon, Sep 09
Hi,
I got a report today of svn 1.8.3 (tortoise 1.8.2) producing tree conflicts
when a sync up merge was reverted. I ran the merge again with 1.8.3 to confirm
the issue and again using 1.7.8 command line (which worked). See the status
reports below (a bit hacked manually to remove some sensitiv
-Original Message-
From: Johan Corveleyn [mailto:jcor...@gmail.com]
Sent: 09 September 2013 14:13
To: James French
Cc: users@subversion.apache.org
Subject: Re: svn: E120104: ra_serf: An error occurred during decompression
On Mon, Sep 9, 2013 at 3:02 PM, James French
wrote:
> I tr
1.8.0.
* OpenSSL 1.0.1e.
* Serf 1.2.1.
* Neon removed.
-Original Message-
From: James French [mailto:james.fre...@naturalmotion.com]
Sent: 09 September 2013 14:03
To: Johan Corveleyn
Cc: users@subversion.apache.org
Subject: RE: svn: E120104: ra_serf: An error occurred during decompre
I tried it again with the 1.8.3 command line and the merge went through...
-Original Message-
From: Johan Corveleyn [mailto:jcor...@gmail.com]
Sent: 09 September 2013 13:36
To: James French
Cc: users@subversion.apache.org
Subject: Re: svn: E120104: ra_serf: An error occurred during
-Original Message-
From: Johan Corveleyn [mailto:jcor...@gmail.com]
Sent: 09 September 2013 13:36
To: James French
Cc: users@subversion.apache.org
Subject: Re: svn: E120104: ra_serf: An error occurred during decompression
On Mon, Sep 9, 2013 at 1:14 PM, James French
wrote:
> Hi l
: James French; users@subversion.apache.org
Subject: RE: E120104: ra_serf: An error occurred during decompression
The current TortoiseSVN is already compiled against serf 1.3 as far as I can
tell.
(TortoiseSVN uses its own custom build system and this patch just affects the
build system
Hi list,
I hit this when doing a reintegrate merge with svn 1.8.3 (tortoisesvn 1.8.2). I
repeated the operation with svn 1.7.8 and it did not occur. The following
section in the STATUS file looks highly relevant:
* ^/subversion/branches/1.8.x-serf-1.3+-windows
Allow compiling against serf 1.
Hi,
If I update a folder with -set-depth=empty and then update a child folder with
-set-depth=infinity the parent is still reported as having empty depth by svn
info. This is with svn 1.7.6.
Is this by design? Seems weird to me...
James
ld
affect this?
____
From: James French [james.fre...@naturalmotion.com]
Sent: 05 October 2012 12:59
To: users@subversion.apache.org
Subject: RE: svn:eol-style native and reintegrate merge
http://svn.apache.org/viewvc?view=revision&revision=1355703
Fix a bug in propset which could prev
.7.6 fix and it sounds scarily pertinent
From: James French [james.fre...@naturalmotion.com]
Sent: 05 October 2012 09:58
To: users@subversion.apache.org
Subject: RE: svn:eol-style native and reintegrate merge
From: James French [james.fre...@naturalmotion.com]
Sent: 04 October 2012 22:39
To: users@subversion.apache.org
Subject: svn:eol-style native and reintegrate merge
Hi,
Using svn 1.7.6 and working on a dev branch I wrote a script to set
svn:eol-style
Hi,
Using svn 1.7.6 and working on a dev branch I wrote a script to set
svn:eol-style=native on all source code files, because we develop on Mac and
PC. When I tried to check in it kept failing on files that had inconsistent
line endings so I kept fixing them until I was able to check in. So fa
Hi,
Using svn 1.7.6 and working on a dev branch I wrote a script to set
svn:eol-style=native on all source code files, because we develop on Mac and
PC. When I tried to check in it kept failing on files that had inconsistent
line endings so I kept fixing them until I was able to check in. So fa
Hi,
Using svn 1.7.6 and working on a dev branch I wrote a script to set
svn:eol-style=native on all source code files, because we develop on Mac and
PC. When I tried to check in it kept failing on files that had inconsistent
line endings so I kept fixing them until I was able to check in. So fa
From: Stefan Sperling [s...@elego.de]
Sent: 28 August 2012 15:03
To: James French
Cc: users@subversion.apache.org
Subject: Re: 'invalid status for updateting properties' error during
reintegrate merge (was: no subject)
On Tue, Aug 28, 2012 at
Hi,
Using svn 1.7.6 I've had an error a couple of times on reintegration. Here is
the scenario:
- A file called checkBackwardsCompatibilty.bat is on trunk and has merge info
on it (I don't want it to but that's a separate discussion).
- The merge info on this file gets updated regularly as peop
Hi,
I just noticed that svn 1.6 did not url encode the output of svn diff
-summarize (ie spaces in files not replaced with %20), whereas svn 1.7 does.
There is nothing in changes.txt about it. Is the 1.7 behaviour correct?
Cheers,
James
From: Stefan Sperling [s...@elego.de]
Sent: 26 June 2012 10:06
To: James French
Cc: users@subversion.apache.org
Subject: Re: moving files in repobrowser generates mergeinfo
On Tue, Jun 26, 2012 at 09:47:06AM +0100, James French wrote:
> Thanks Stefan
From: Stefan Sperling [s...@elego.de]
Sent: 25 June 2012 18:59
To: James French; users@subversion.apache.org
Subject: Re: moving files in repobrowser generates mergeinfo
On Mon, Jun 25, 2012 at 07:55:05PM +0200, Stefan Sperling wrote:
> On Mon, Jun
Hi group,
I know this could be seen as a tortoise svn question, but I was wondering if
there was anything in subversion itself that would want to put merge info on
files moved via a repo browser (1.6 and 1.7). This does not happen when doing
moves client side (tortoise or command line).
Cheers
-Original Message-
From: Stefan Sperling [mailto:s...@elego.de]
Sent: 25 June 2012 15:41
To: Attila Nagy
Cc: Philip Martin; users@subversion.apache.org
Subject: Re: svn rm much slower on 1.7.5 than on 1.6 (with SQL timings)
On Mon, Jun 25, 2012 at 04:33:50PM +0200, Attila Nagy wrote:
>
Sorry for late reply - thanks for that information Johan. Glad that there's
work going on in this area :)
-Original Message-
From: Johan Corveleyn [mailto:jcor...@gmail.com]
Sent: 18 April 2012 16:32
To: James French
Cc: Les Mikesell; Subversion Users
Subject: Re: default ignore
From: Les Mikesell [lesmikes...@gmail.com]
Sent: 17 April 2012 19:34
To: James French
Cc: Subversion Users
Subject: Re: default ignores
On Tue, Apr 17, 2012 at 1:08 PM, James French
wrote:
>
> I would say that it is up to the user to check their
-Original Message-
From: Les Mikesell [mailto:lesmikes...@gmail.com]
Sent: 17 April 2012 16:57
To: James French
Cc: Subversion Users
Subject: Re: default ignores
On Tue, Apr 17, 2012 at 10:18 AM, James French
wrote:
> Hi group,
>
>
>
> Just wanted to have a bit of
Hi group,
Just wanted to have a bit of rant about the default ignores that subversion
clients have since its cost us so much time and hassle. I would like to argue
that there should be no default ignores - let the client (customer) deal with
it.
The '.a' ignore has particularly hurt us. I've l
Hi,
I understand sparse checkouts but is there a recommended way of doing 'sparse
branches'? Often projects need to be farmed out to a release branch and then
deleted from the main trunk (to save space). It is then necessary to do the
inverse on the new branch ie delete all the projects that ar
-Original Message-
From: KARR, DAVID [mailto:dk0...@att.com]
Sent: 08 November 2011 20:31
To: users@subversion.apache.org
Subject: Good strategies for incorporating an external code drop
Subversion works fine when developers have access to the SVN repo. I'm working
on a project where
-Original Message-
From: Stefan Sperling [mailto:s...@elego.de]
Sent: 26 October 2011 11:29
To: James French
Cc: users@subversion.apache.org
Subject: Re: Behaviour of reintegrate in 1.7.1
On Wed, Oct 26, 2011 at 10:02:17AM +0100, James French wrote:
> I was prompted to give 1.7.
Hi guys,
Firstly, thanks for all the enormous effort on svn 1.7.x, and for all the great
support. I have high hopes for 1.7. Its great to see all those .svn folders
banished.
I was prompted to give 1.7.1 a shot when a reintegrate merge task turned up
where the destination checkout was sparse,
Upgrading to svn 1.7 whose principal feature is a major change to the working
copy, with local mods, is just plain dumb.
From: Igor d [mailto:igoro...@gmail.com]
Sent: 18 October 2011 15:20
To: Igor d; users@subversion.apache.org
Subject: Re: Help! Subversion Exception!
But if i have a lot of di
Hi,
We always do merges from the root of the repository. When these merges are done
svn always marks up the mergeinfo on all first level files and folders as well
as the root folder itself. Is this working as intended? We have had a practice
for quite a while, dating back to buggy releases wher
Hi,
We always do merges from the root of the repository. When these merges are done
svn always marks up the mergeinfo on all first level files and folders as well
as the root folder itself. Is this working as intended? We have had a practice
for quite a while, dating back to buggy releases wher
38 matches
Mail list logo
