I first described my issue in the form of the Issue ticket:
http://subversion.tigris.org/issues/show_bug.cgi?id=4462 but it was
promptly closed for unclear reasons.
The explanation in this ticket says "you somehow deleted your current
directory". Well, I am positive I did not.
In short: I had
I hope by "*Somebody else added few files into the repository*" You mean
they have committed the file to the respository as well because just adding
the file to repository would not make those available to others.
It has to be committed as per SVN nomenclature.
Just confirming before we jump to an
On Thu Jan 16 02:08:47 2014, Yuri wrote:
> I first described my issue in the form of the Issue ticket:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4462 but it was promptly
> closed for unclear reasons.
There's nothing unclear about why your ticket was closed. Please read
the top yellow
On Thu, Jan 16, 2014 at 02:08:47AM -0800, Yuri wrote:
> I first described my issue in the form of the Issue ticket:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4462 but it was promptly
> closed for unclear reasons.
> The explanation in this ticket says "you somehow deleted your current
>
On 01/16/2014 03:04, Ashish Kaushik wrote:
I hope by "/Somebody else added few files into the repository/" You
mean they have committed the file to the respository as well because
just adding the file to repository would not make those available to
others.
It has to be committed as per SVN nom
Hello all,
I have come across the following situation:
- With SVN client 1.8.x (specifically Tortoise 1.8.4), I'm not able to
checkout public repositories when behind a (company) web proxy. You can try as
an example to checkout from http://net-orcades-spring.googlecode.com/svn/trunk.
Hi,
We tested Subversion (and serf) with a number of different proxy servers and
that worked correctly. Without knowledge of how we can reproduce your
problem there is nothing we can do. And adding an issue to our issue tracker
without something we can do is a complete waste of
Yuri writes:
> The major difference is that this file has two records in "Bad DB" and
> only one record in "Good DB". Bad DB has an extra record with
> op_depth=4 and 'base-deleted'.
>
> I never deleted those files, I added them myself locally because they
> are new, but never checked them in.
T
Hello,
I keep a local svn checkout in sync with a svn repository on the
server (without making any local changes).
I probably created the repository with subversion 1.6 (and also did
the checkout with the same version) and later upgraded both the
original repository and the checkout to version 1.
On Thu, Jan 16, 2014 at 02:49:56PM +0100, Mojca Miklavec wrote:
> Hello,
>
> I keep a local svn checkout in sync with a svn repository on the
> server (without making any local changes).
>
> I probably created the repository with subversion 1.6 (and also did
> the checkout with the same version)
Mojca Miklavec writes:
> Is there any painless way to shrink the size of the local .svn folder
> (other than deleting everything and fetching the whole 6 GB again)?
'svn cleanup'
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Though this is years late.. I believe what you want is to do the command:
svn update --set-depth exclude
It is documented here:
http://svnbook.red-bean.com/en/1.6/svn.advanced.sparsedirs.html
--
View this message in context:
http://subversion.1072662.n5.nabble.com/How-to-un-checkout-from-sv
(please CC: me as not subscribed)
Hi.
The bug report "rep-cache.db created without group write bit" [0] seems
to be on the way of being solved (AFAIU, the fix isn't released yet).
So, until then, for new repositories where no commit was made, a workaround
is to create (touch) the file before the
Hi.
I got a SIGSERV error while running 'svn update'.
I have Debian 7.1 (3.2.0-4-686-pae #1 SMP Debian 3.2.51-1 i686)
with svn, version 1.6.17 (r1128011) compiled Oct 4 2013, 03:24:06
(from Debian portage tree)
I ran it under gdb:
(gdb) run up
Starting program: /usr/bin/svn up
[Thread debuggin
We are running into an issue similar to the one described in
http://svn.haxx.se/users/archive-2013-12/0171.shtml when performing some sync
merges. svn issues error "E195016: Reintegrate can only be used if revisions…”
but this isn’t a reintegrate merge. When this happens, the only work around
a
Hi,
i observed a strange thing during a checkin process running where i got
the following messages:
Karl-Heinzs-MacBook-Pro:exec-maven-plugin kama$ svn ci -F x.diff
Sendingsrc/it/mexec-100/pom.xml
Sendingsrc/it/mexec-105/pom.xml
Transmitting file data ..
Committed revision 1931
Hi,
furthermore i have recodnized that the local files are currently in the
state of modified:
Karl-Heinzs-MacBook-Pro:exec-maven-plugin kama$ svn st
M src/it/mexec-100/pom.xml
M src/it/mexec-105/pom.xml
which is really strange, cause the files i have changed the above two
pom fi
On Thu, Jan 16, 2014 at 1:23 PM, Karl Heinz Marbaise wrote:
> i observed a strange thing during a checkin process running where i got
> the following messages:
>
> Karl-Heinzs-MacBook-Pro:exec-maven-plugin kama$ svn ci -F x.diff
> Sendingsrc/it/mexec-100/pom.xml
> Sendingsrc/it/me
Hi,
so after i did an svn up i got this:
Karl-Heinzs-MacBook-Pro:exec-maven-plugin kama$ svn up
Updating '.':
Gsrc/it/mexec-100/pom.xml
Gsrc/it/mexec-105/pom.xml
more or less expected
> Hi,
furthermore i have recodnized that the local files are currently in the
state of modified:
On 1/16/14, 8:34 AM, Keath Milligan wrote:
> We are running into an issue similar to the one described in
> http://svn.haxx.se/users/archive-2013-12/0171.shtml when performing some sync
> merges. svn issues error "E195016: Reintegrate can only be used if
> revisions…” but this isn’t a reintegrat
On Thu, Jan 16, 2014 at 3:03 PM, Stefan Sperling wrote:
> On Thu, Jan 16, 2014 at 02:49:56PM +0100, Mojca Miklavec wrote:
>>
>> Is there any painless way to shrink the size of the local .svn folder
>> (other than deleting everything and fetching the whole 6 GB again)?
>
> 'svn cleanup'
> http://sub
On 1/16/14, 6:08 AM, Olivier Berger wrote:
> (please CC: me as not subscribed)
>
> Hi.
>
> The bug report "rep-cache.db created without group write bit" [0] seems
> to be on the way of being solved (AFAIU, the fix isn't released yet).
Correct, no release includes this yet. I don't think it's be
Thanks Ben, we are unable to reproduce this in a simple repo but we are
continuing to investigate.
We did notice something odd in the mergeinfo of the affected branch though. It
lists a set of revisions for *itself*, which we don’t see elsewhere. Is this
valid? This repo has had a lot of activ
Karl Heinz Marbaise writes:
> Hi,
>
> so after i did an svn up i got this:
>
> Karl-Heinzs-MacBook-Pro:exec-maven-plugin kama$ svn up
> Updating '.':
> Gsrc/it/mexec-100/pom.xml
> Gsrc/it/mexec-105/pom.xml
>
> more or less expected
>
>> furthermore i have recodnized that the local fil
Philip Martin writes:
Karl-Heinzs-MacBook-Pro:exec-maven-plugin kama$ svn ci -F x.diff
Sendingsrc/it/mexec-100/pom.xml
Sendingsrc/it/mexec-105/pom.xml
Transmitting file data ..
Committed revision 19310.
svn: E120108: Commit failed (details follow):
>>
I need a sanity check. Is this an oversight that needs to be corrected, or am
I missing something?
Problem:
"svn log -g" will explicitly identify a reverse merge, however, when specifying
xml output ("svn log -g --xml") no such identification is made.
Example:
In this case, r13 on bra
> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: donderdag 16 januari 2014 20:59
> To: i...@soebes.de
> Cc: users@subversion.apache.org
> Subject: Re: Bug ? With SVN 1.8.4 on Mac
>
> Karl Heinz Marbaise writes:
>
> > Hi,
> >
> > so after i did an s
On 1/16/14, 12:34 PM, Bert Huijben wrote:
> That script is only going to help you for the platform invariant error codes
> in Subversion itself + the codes on the platform you are checking on.
It knows about APR's errors as well (not that this is important in this case),
see the aprerr.txt file in
On 1/16/14, 12:31 PM, Andrew Reedick wrote:
> I need a sanity check. Is this an oversight that needs to be corrected, or
> am I missing something?
>
> Problem:
> "svn log -g" will explicitly identify a reverse merge, however, when
> specifying xml output ("svn log -g --xml") no such identif
On 1/16/14, 1:38 PM, Ben Reser wrote:
> On 1/16/14, 12:31 PM, Andrew Reedick wrote:
>> I need a sanity check. Is this an oversight that needs to be corrected, or
>> am I missing something?
>>
>> Problem:
>> "svn log -g" will explicitly identify a reverse merge, however, when
>> specifying xm
On 1/16/14, 1:59 PM, Ben Reser wrote:
> Opened issue #4463 for this:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4463
Fixed in r1559032. I anticipate that the fix will be included in 1.9.0.
31 matches
Mail list logo
