Guten Tag Trent W. Buck,
am Dienstag, 10. September 2013 um 02:49 schrieben Sie:
> ...hm, still 1.6. Is it worth me backporting a newer svn?
I would give it a try, get yourself a current build of 1.8, dump your
old repo and load it into a newly created from your 1.8 version and
see how much spac
Guten Tag ºÚÉÁÖ,
am Dienstag, 10. September 2013 um 01:07 schrieben Sie:
>> (5)invoke "maked resolved" menu,checked "Resolve conflicts in local file
>> with my changes" option, Test.java file content change bottom:
[...]
>> (6)My question is, why don't you into the following this?
Look at 5, you
Les Mikesell writes:
> On Mon, Sep 9, 2013 at 7:23 PM, Trent W. Buck wrote:
>> Ryan Schmidt writes:
>>
>>> As someone used to Subversion's usually sequential revision numbers,
>>> that bugs me aesthetically, but it works fine.
>>
>> I think that's the crux of it.
>
> Have you checked if the use
On Mon, Sep 9, 2013 at 7:23 PM, Trent W. Buck wrote:
> Ryan Schmidt writes:
>
>> As someone used to Subversion's usually sequential revision numbers,
>> that bugs me aesthetically, but it works fine.
>
> I think that's the crux of it.
Have you checked if the users have/need anything (emails, tic
trentb...@gmail.com (Trent W. Buck) writes:
> So then I thought to chain the two approaches. This didn't work -- the
> empty revs were not removed. I guess svndumpfilter --drop-empty-revs
> is only smart enough to drop the revs that have just *become* empty?
>
> rm -rf delete-me-3
> svnadm
I built 1.8.3 from the source tar ball and then ran "make check". I'm using
10.8.4 with Xcode 4.6.3.
depth_test.py fails with:
> W: svn: E200030: sqlite[S4]: callback requested query abort
> W: svn: E200030: Additional errors:
> W: svn: E200030: sqlite[S4]: callback requested query abort
> W: CW
> (1)myeclipse1 create java file content:
> package test;
>
> public class Test {
>
> public static void main(String[] args) {
> System.out.println("1");
> System.out.println("2");
> System.out.println("3");
> System.out.println("4");
> System.out.println("5");
> System.out.println("6");
> System.o
Thorsten Schöning writes:
> Tell us about the size of your repo
> it's format version and primary data types versioned
(Sorry for not giving this info earlier, and shifting the goal posts --
I personally went rcs->arch->darcs->git and never really used svn, so
I'm feeling pretty noob attacking t
Ryan Schmidt writes:
> As someone used to Subversion's usually sequential revision numbers,
> that bugs me aesthetically, but it works fine.
I think that's the crux of it. Also part of the reason to split up the
repos is to make access control easier, and it looks bad if Alice (who
should have
On Sep 9, 2013, at 07:31, Les Mikesell wrote:
> On Sun, Sep 8, 2013 at 8:13 PM, Trent W. Buck wrote:
>
>> I'm stuck. Since it's no fun to have tens of thousands of empty revs
>> in each project repo, my current approach is to leave existing
>> projects in the monolithic repo, and new projects g
On Mon, Sep 09, 2013 at 02:37:05PM +0100, James French wrote:
> 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
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,
On Mon, Sep 9, 2013 at 8:03 AM, Grierson, David
wrote:
> I can see Trent's view point that people are weird and get freaked out by the
> unexpected (where they might expect the revision numbers to be relatively
> low).
>
I could see that for someone who had never used subversion before and
did
Subversion 1.8 throws up errors when I specify HTTP/HTTPS URLs that contain
usernames to svn, i.e.
svn --username user ls https://server.com/repos/project/
works fine but
svn ls https://u...@server.com/repos/project/
results in errors. The same URL worked fine with Neon in 1.7 and older. T
On Mon, Sep 9, 2013 at 9:20 AM, James French wrote:
>
>
> -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
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 tried i
On Mon, Sep 9, 2013 at 3:02 PM, James French
wrote:
> I tried it again with the 1.8.3 command line and the merge went through...
Okay, I'm happy for you that it worked :-). However, I'm not convinced
the error is gone. In my case it would also only fail intermittently.
I couldn't reproduce it all
I guess the final thing to add is that I was using 1.8.1 collabnet x64 and
1.7.3 wandisco 1.8.3 (serf 1.3.1). The 1.8.1 version doesn't report which
version of serf is being used but their changelog indicates it might be 1.2.1:
Version 1.8.1
https://dist.apache.org/repos/dist/dev/subvers
Well, I'm running everything I know about in English so I guess that should not
be a problem, right?
/B
From: Albertsen, Ketil [mailto:ketil.albert...@nordicsemi.no]
Sent: den 9 september 2013 14:57
To: Bjarne Grönnevik; Bert Huijben; users@subversion.apache.org
Subject: RE: SilkSVN client crash
I can see Trent's view point that people are weird and get freaked out by the
unexpected (where they might expect the revision numbers to be relatively low).
I guess what we should be providing him are points like you do make to help him
sell why this isn't an issue to the end users.
Like Les s
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 decomp
Maybe unrelated to your problem, but worth checking up anyway:
We had lots of problems with SlikSVN until we discovered that some users had
selected that SVN client because it offered a user interface in their native
language, including translations of those error messages parsed by SVN. Once
t
-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 list,
On Mon, Sep 9, 2013 at 1:14 PM, James French
wrote:
> 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.
This looks very much like the error I ran into during testing of
1.8.3, and which sp
On Sun, Sep 8, 2013 at 8:13 PM, Trent W. Buck wrote:
>
> I'm stuck. Since it's no fun to have tens of thousands of empty revs
> in each project repo, my current approach is to leave existing
> projects in the monolithic repo, and new projects get separate repos.
>
Why do you think an empty rev w
Hmm, actually I made a mistake. The merge was done through our own gui tool
that actually uses svn 1.8.1 command line. Looks like there are a few serf
fixes in 1.8.3 but the status entry I found looks very suspicious.
From: Bert Huijben [mailto:b...@qqmail.nl]
Sent: 09 September 2013 12:51
To: J
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)
Bert
From: James French [mailto:james.fre...@naturalmotion.com]
Sent: maandag 9 september 2013 13:
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 again,
I'm not really familiar with VS (nowadays :)), but are you saying that if I
place the pdb:s in the same dir as the svn.exe (C:\Program Files\SlikSvn\bin on
my machine), the crash log will contain better info for you guys? If so I can
totally do that.
/Bjarne
From: Bert Huijben [mail
30 matches
Mail list logo
