Matthias Legeler wrote on Thu, Jun 27, 2013 at 10:30:32 +:
> 'svn propget --strict svn:mergeinfo ./ ' gets the first 7895 characters
> 'svn propget --strict svn:mergeinfo URL' gets all 7959 characters
>
> yes, 64 characters difference
>
Interesting, thanks.
I guess the next step is to look
Greg Stein wrote on Thu, Jun 27, 2013 at 20:10:55 +:
> On Thu, Jun 27, 2013 at 05:51:22PM +0100, Philip Martin wrote:
> > George Schizas writes:
> >
> > > know if I should also post this to the dev list
> >
> > Yes, patches to dev please.
>
> No need. I've already patched it: r1497551. We s
On Thu, Jun 27, 2013 at 05:51:22PM +0100, Philip Martin wrote:
> George Schizas writes:
>
> > know if I should also post this to the dev list
>
> Yes, patches to dev please.
No need. I've already patched it: r1497551. We should backport this to
the 1.8.x series.
Thanks, George!
Cheers,
-g
George Schizas writes:
> know if I should also post this to the dev list
Yes, patches to dev please.
--
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
www.wandisco.com
When doing an svn checkout (or svn update), on a repo that is served by
Apache httpd with IIS as a reverse proxy (you are connecting to IIS, not
directly Apache), a HTTP 400 error is thrown (really from IIS).
The problem is that the Accept-Encoding header is the following:
gzip;svndiff1;q=0.9,svn
On Thu, Jun 27, 2013 at 7:06 AM, Nico Kadel-Garcia wrote:
>>> http://svnbook.red-bean.com/en/1.7/svn.advanced.props.special.ignore.html
>>
>> In summary: this is a way to tell svn to ignore a file (or filename pattern)
>> when looking for files to check-in. Hence the file itself is not in the
Hi,
I have a question regarding the right behavior of info and status commands on
file externals and new files resisting in 'X'-folders. This is what I do:
jruhe@wheezy:~$ svn co
svn://wheezy.wks.berl.axway.int/ms_automatic/mapping_services/projects/scratch%20pad/DML_EMPTY
ADML_EMPTY/Docum
On Thu, Jun 27, 2013 at 6:50 AM, Cooke, Mark wrote:
> [Please post inline, it makes it easier to follow...]
>
>> Message original
>> Sujet: Re: Question about subversion
>> De : Cooke, Mark
>> Pour : Marc Davenne , Andrew Reedick
>>
>> Copie à : "users@subversion.apache.org"
>
[Please post inline, it makes it easier to follow...]
> Message original
> Sujet: Re: Question about subversion
> De : Cooke, Mark
> Pour : Marc Davenne , Andrew Reedick
>
> Copie à : "users@subversion.apache.org"
> Date : 27/06/2013 11:40
>
> >> -Original Message-
>
'svn propget --strict svn:mergeinfo ./ ' gets the first 7895 characters
'svn propget --strict svn:mergeinfo URL' gets all 7959 characters
yes, 64 characters difference
Matthias
-Original Message-
From: Daniel Shahaf [mailto:danie...@elego.de]
Sent: Donnerstag, 27. Juni 2013 12:18
To: Ma
Matthias Legeler wrote on Thu, Jun 27, 2013 at 07:02:50 +:
> In our subversion repositories we have merged many many times.
> Now we have very large svn:mergeinfo property values (>8k).
> The problem is now, that if we make a svn checkout, the property values will
> be truncated in the working
I am not sure I understand it very well. When you say it is ignored,
does it mean it is on svn ?
And what is this script that would trigger on checkout ?
Can you explain it again ?
Message original
Sujet: Re: Question about subversion
De : Cooke, Mark
Pour : Marc Davenne , An
Philip Martin wrote on Thu, Jun 27, 2013 at 11:00:23 +0100:
> Matthias Legeler writes:
>
> > In our subversion repositories we have merged many many times.
> > Now we have very large svn:mergeinfo property values (>8k).
> > The problem is now, that if we make a svn checkout, the property values
Michael Schlottke wrote on Wed, Jun 26, 2013 at 17:34:15 +0200:
>
> On Jun 21, 2013, at 15:23 , Philip Martin wrote:
> > Another user raised the issue
> >
> > http://subversion.tigris.org/issues/show_bug.cgi?id=4382
> >
> > Using '--diff-cmd colordiff' to get coloured output no longer works.
> >
yes, this returns the full correct value.
The svn checkout via http makes the problem, tested with server 1.6.9 and
client 1.6.x and 1.8.0.
regards
Matthias
-Original Message-
From: Philip Martin [mailto:philip.mar...@wandisco.com]
Sent: Donnerstag, 27. Juni 2013 12:00
To: Matthias Lege
Matthias Legeler writes:
> In our subversion repositories we have merged many many times.
> Now we have very large svn:mergeinfo property values (>8k).
> The problem is now, that if we make a svn checkout, the property values will
> be truncated in the working copy by approximately 8k.
> The svn
> -Original Message-
> From: Marc Davenne [mailto:marc.dave...@cramif.cnamts.fr]
> Sent: 27 June 2013 10:25
> To: Andrew Reedick
> Cc: users@subversion.apache.org
> Subject: Re: Question about subversion
>
> Thank you for your answers... all of you
>
> @Andrew
> Thank you, the answers yo
[ Please use reply all to keep the list in the loop. Also, please
don't top-post, i.e. put your reply inline or below the thing you're
replying to. More below ... ]
> -Original Message-
> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> Sent: Donnerstag, 27. Juni 2013 09:58
> To: Matthia
Thank you for your answers... all of you
@Andrew
Thank you, the answers you gave were exactly what I thought about (I was
a little bit too general when I asked the question)
- concerning answer number 2 (specific files)
Let's say I have a parameter file with paths for my dev environement.
Typ
On Thu, Jun 27, 2013 at 9:02 AM, Matthias Legeler
wrote:
> In our subversion repositories we have merged many many times.
> Now we have very large svn:mergeinfo property values (>8k).
> The problem is now, that if we make a svn checkout, the property values will
> be truncated in the working copy
In our subversion repositories we have merged many many times.
Now we have very large svn:mergeinfo property values (>8k).
The problem is now, that if we make a svn checkout, the property values will be
truncated in the working copy by approximately 8k.
The svn propget command at the working copy
21 matches
Mail list logo
