On Jun 2, 2010, at 21:56, 刘国庆 wrote:
> I use all the subversion version, all the error, how are make not the past,
> please help us to see what it is.
>
>
> [r...@localhost subversion-1.6.11]# make
> /bin/sh /opt/src/subversion-1.6.11/libtool --tag=CC --silent --mode=compile
> gcc -DLINUX=2
I use all the subversion version, all the error, how are make not the past,
please help us to see what it is.
[r...@localhost subversion-1.6.11]# make
/bin/sh /opt/src/subversion-1.6.11/libtool --tag=CC --silent --mode=compile gcc
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -g -
This is very interesting. But it looks to me like it links to
javascript on your server in order to function? In other words, if I
need access to my bug tracker and your server is - for some reason -
offline, I'm SOL?
Thanks
Rob
Fyodor Sheremetyev wrote:
Dear Subversion users,
We are ple
Ryan Schmidt wrote on Wed, 2 Jun 2010 at 17:35 -0500:
> On Jun 2, 2010, at 13:48, Paul Breen wrote:
>
> > I previously inquired about adding a –skipfilesmatchingsize option
> > to the export subcommand. I have implemented that feature, and
> > I was wondering if it has any chance of making it int
Ryan Schmidt wrote on Tue, 1 Jun 2010 at 16:23 -0500:
> On Jun 1, 2010, at 06:52, Mauro Gatti wrote:
> > [ ... about post-commit hooks ... ]
>
> Hmm. I wasn't aware it was possible for $1 to not contain the full
> absolute path to the repository. I wonder why in your case it isn't.
The code doesn
On Wed, Jun 2, 2010 at 8:46 PM, Michael Zatopek wrote:
> Hi,
>
> I'm getting a vague error. I have subversion set up through apache on
> freebsd(all installed through ports). I'm working with a large repository
> containing lots of large files which I've migrated over from an older
> similar insta
On Jun 2, 2010, at 13:48, Paul Breen wrote:
> I previously inquired about adding a –skipfilesmatchingsize option to the
> export subcommand. I have implemented that feature, and I was wondering if
> it has any chance of making it into the trunk directory for svn. It
> currently has performanc
On Wed, Jun 02, 2010 at 05:45:53PM -0400, Brian Pitts wrote:
> It is a little hard to wrap my head around the idea that although I
> committed the change deleting foo/bar, I now have to update foo/ for
> my working copy to truly reflect that foo/bar is deleted. To
> paraphrase Johan from #3256, 'wh
On 06/02/2010 04:04 PM, Stefan Sperling wrote:
Look at the output of
svn info foo
at this point. You'll see that foo is not at the HEAD revision,
i.e. something older than 1740.
foo/bar was bumped to the HEAD revision because it was a commit target.
But foo was not a commit target so it is le
On Wed, Jun 2, 2010 at 12:46, Stefan Sperling wrote:
> On Wed, Jun 02, 2010 at 12:37:13PM +0200, Stefan Sperling wrote:
>> We should figure out how log -g should behave in this case (the behaviour
>> you're seeing clearly isn't desirable) and then fix it.
>> Please file an issue.
>
> Oh, and if yo
On Wed, Jun 02, 2010 at 01:04:38PM -0400, Brian Pitts wrote:
> Hi,
>
> I'm experiencing a tree conflict in a situation where there should be no
> conflict. Basically, after removing the contents of a directory I'm
> unable to commit deleting the directory even though no one has modified
> it. The
Hello,
I previously inquired about adding a –skipfilesmatchingsize option to the
export subcommand. I have implemented that feature, and I was wondering if it
has any chance of making it into the trunk directory for svn. It currently has
performance issues, and I don't want to spend a lot of
Hi,
I'm getting a vague error. I have subversion set up through apache on
freebsd(all installed through ports). I'm working with a large
repository containing lots of large files which I've migrated over
from an older similar install on another machine using svnadmin dump/
restore.
I can
On Wednesday 02 Jun 2010, yary wrote:
> Hi Campbell,
>
> I can build a working binary as well, it's just that the client
> doesn't have the http: method when built with only serf and
> "--without-neon". It sounds like you're building it with neon in each
> cases, just not using the "--with-neon" f
Hi,
I'm experiencing a tree conflict in a situation where there should be no
conflict. Basically, after removing the contents of a directory I'm
unable to commit deleting the directory even though no one has modified
it. The client is 1.6.6. I've tried with server versions 1.4.3 and
1.6.9. Below i
Hi Campbell,
I can build a working binary as well, it's just that the client
doesn't have the http: method when built with only serf and
"--without-neon". It sounds like you're building it with neon in each
cases, just not using the "--with-neon" flag; omitting the flag makes
configure look for it
On Tuesday 01 Jun 2010, yary wrote:
> Neon is required? The INSTALL that comes with 1.6.11 says that either
> neon or serf will give http access:
>
> * libneon or libserf (OPTIONAL for client)
>
> The Neon and Serf libraries both allow the Subversion client
> to send HTTP
The new directories did not exist in the trunk.
I eventually "merged" my changes from the branch to the trunk by doing a diff
between the working copies of the branch and trunk. The svn merge did get some
of the changed files, but the tree conflicts seem random.
I tried again this morning
--
httpd-2.2.14/modules/dav/main/mod_dav.h :
DAV_DECLARE(dav_error*) dav_new_error(apr_pool_t *p, int status,
int error_id, const char *desc);
--
ht
Dear Subversion users,
We are pleased to announce the public availability of "Artifacts for
Web" BETA - free web-based bug tracker.
http://www.versioned.com/artifacts/web/
There is no need to install server software to use Artifacts. If you
have a Subversion repository then you can start using a
On Wed, Jun 02, 2010 at 12:37:13PM +0200, Stefan Sperling wrote:
> We should figure out how log -g should behave in this case (the behaviour
> you're seeing clearly isn't desirable) and then fix it.
> Please file an issue.
Oh, and if you can, please write a small script (attached to the issue)
or
On Wed, Jun 02, 2010 at 11:33:21AM +0200, B Smith-Mannschott wrote:
> A few clever people suggested a way around the delete-and-recreate the
> branch problem. Just use a record-only merge to make the topic branch
> aware of the reintegration revision on trunk without actually enduring
> the resulti
Bah!! (I'm a just a wee bit frustrated as I write this, please forgive
any roughness in tone.)
After waiting patiently for $JOB to finally move our server to
Subversion 1.6, I'm finding Subversion's merge tracking to be rather
less help than I'd hoped. (I guess git/hg/bzr have spoiled me during
my
23 matches
Mail list logo
