headers
Kouhei Sutou | 1 Jan 2007 01:00
Favicon
Gravatar

Re: [PATCH] Ruby binding core test mods to pass Windows line endings

Hi,

In <ae6cb1100612311133t1dfba68cl6e50f406540fc613 <at> mail.gmail.com>
  "[PATCH] Ruby binding core test mods to pass Windows line endings" on Sun, 31 Dec 2006 11:33:53 -0800,
  "Joe Swatosh" <joe.swatosh <at> gmail.com> wrote:

> [[[
> * subversion/bindings/swig/ruby/test/test_core.rb
>   Change "\n" to "\r\n" in the expected strings when running on
> windows platform.
> 
> ]]]

I've merged and used another way too. Could you check my
changes on your Windows environment?

Thanks,
--
kou
Permalink | Reply | 1 comment |
headers
Branko Čibej | 1 Jan 2007 01:08
Picon

It's been an interesting year ... hope the next one is even better!

Permalink | Reply | 501 comments |
headers
David James | 1 Jan 2007 01:25
Picon
Favicon

Re: Python: Fetching properties of file without content

On 12/31/06, Shun-ichi GOTO <shunichi.goto <at> gmail.com> wrote:
> 2007/1/1, David James <james <at> cs.toronto.edu>:
> > On 12/31/06, Markus Fuchs <m.fuchs <at> fplusp.com> wrote:
> > > properties = svn.ra.get_file(self.session, self.path, self.rev, None)
> > > Unfortunately this results in an "AttributeError: write" in svn_ra_get_file
> > > (ra.py).
> > >
> > > What am I doing wrong? Is it a bug?
> >
> > Yes, this is a bug in the Python bindings, which I believe was fixed
> > in  Subversion 1.3.0. What version of the Python bindings are you
> > using?
>
> Really?  I've tried with python binding 1.3.0, 1.3.1 and 1.4.2 on Windows
> and 1.3.2 on debian.
> I got same result with all of them: "AttributeError: write".

Oops, you're right! This bug is still present in Subversion trunk.
I've fixed this bug in r22849 in Subversion trunk, so the fix should
be included in Subversion 1.5 when it is released. I've also added
some tests to verify this fix.

If you have time, can you verify my fix on your machine?

Cheers,

David
Permalink | Reply | 0 comments |
headers
Ben Collins-Sussman | 1 Jan 2007 01:43
Favicon
Gravatar

Re: It's been an interesting year ... hope the next one is even better!

You know, a lot of folks accuse Googlers of being a cult, but you Venice Project guys are really starting to scare me.  :-)

Permalink | Reply | 503 comments |
headers
Branko Čibej | 1 Jan 2007 02:30
Picon

Re: It's been an interesting year ... hope the next one is even better!

Ben Collins-Sussman wrote:
> You know, a lot of folks accuse Googlers of being a cult, but you
> Venice Project guys are really starting to scare me.  :-)

Unlike Googlers, who are cult, /we/ are culture. :p

Sinifesela ukhisimusi omuhle nonyaka omusha onempumelelo
Permalink | Reply | 0 comments |
headers
Curtis W. Ruck | 1 Jan 2007 09:03
Picon
Favicon

Feature request (Ignore files for svn import/add/commit on the client or silently ignoring on the server)

I am trying to setup svn for the first time, and my local copy of the repository after tinkering/fixing/etc... ends up having .pyc & .pyo files littering everywhere.  Is there anyway to get the server to silently ignore allowing these files to enter the repository?  Or at least the client so they don't end up polluting the repository without me having to remember to cleanse the tree prior to every commit?

Curtis
Permalink | Reply | 2 comments |
headers
Ben Collins-Sussman | 1 Jan 2007 14:04
Favicon
Gravatar

Re: Feature request (Ignore files for svn import/add/commit on the client or silently ignoring on the server)

On 1/1/07, Curtis W. Ruck <ruckc <at> yahoo.com> wrote:
>
> I am trying to setup svn for the first time, and my local copy of the
> repository after tinkering/fixing/etc... ends up having .pyc & .pyo files
> littering everywhere.  Is there anyway to get the server to silently ignore
> allowing these files to enter the repository?  Or at least the client so
> they don't end up polluting the repository without me having to remember to
> cleanse the tree prior to every commit?

Are you running 'svn add *' before every commit?  I don't understand
the use-case.

Either way, try setting the svn:ignore property on your directory, to
make it ignore *.pyc and *.pyo files.  It's described in the svnbook.
Permalink | Reply | 1 comment |
headers
Kamesh Jayachandran | 1 Jan 2007 17:54
Favicon

RE: [PATCH] svn build fails if apr, apr-util, serf are bundled(revealed by r22832)

Hi,
Just found one more small issue with my clean VPATH build with this patch.

The attached patch fixes that too.

With regards
Kamesh Jayachandran


-----Original Message-----
From: Kamesh Jayachandran [mailto:kamesh <at> collab.net]
Sent: Sun 12/31/2006 9:11 PM
To: dev <at> subversion.tigris.org
Subject:  [PATCH] svn build fails if apr, apr-util, serf are bundled(revealed by r22832)

Hi All,

Post r22832 svn build fails if apr, apu, serf all bundled in the subversion
src dir.

The cause is bundled apr/apr-util is identified as ./apr/apr-config and
./apr-util/apu-config for other consumers like serf.
This causes serf's configure to fail.(serf's configure is done from the
directory $SVN_SRC_DIR/serf. so './apr/apr-config and ./apr-util/apu-config
does not make sense).

The fix is to make apr_config and apu_config as absolute path.

While checking in r22832 I tested out only serf being bundled(apr/apr-util detected from the system), and tried other combinations like --without-neon and no --without-neon(I have neon in my system), so did not catch this.

Find the attached patch and log.


With regards
Kamesh Jayachandran


Attachment (bundled_apr_apu_needs_to_be_known_as_full_path.patch): text/x-patch, 1434 bytes
Attachment (bundled_apr_apu_needs_to_be_known_as_full_path.log): text/x-log, 635 bytes
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe <at> subversion.tigris.org
For additional commands, e-mail: dev-help <at> subversion.tigris.org
Permalink | Reply | 5 comments |
headers
Kamesh Jayachandran | 1 Jan 2007 17:59
Favicon

RE: Serf takes more time to complete the tests than dav

Justin,
I tried 1099 of trunk.

I could see the speed improvements.(Now it took 42 mins to complete in my RHEL3).

But with trunk I get the following tests failing in trunk.

FAIL:  merge_tests.py 1: performing a merge, with mixed results
FAIL:  merge_tests.py 2: merge and add new files/dirs with history
FAIL:  merge_tests.py 3: merge that deletes items
FAIL:  merge_tests.py 4: some simple property merges
FAIL:  merge_tests.py 5: merging a file w/no explicit target path using -r
FAIL:  merge_tests.py 7: merge should not die if a target file is absent
FAIL:  merge_tests.py 8: merge on deleted directory in target
FAIL:  merge_tests.py 9: merging similar trees ancestrally unrelated
FAIL:  merge_tests.py 10: merge operations using PREV revision
FAIL:  merge_tests.py 11: merge change into unchanged binary file
FAIL:  merge_tests.py 12: 3-way merge of 'file add' into existing binary
FAIL:  merge_tests.py 15: diff after merge that creates a new file
FAIL:  merge_tests.py 16: merge should skip over unversioned obstructions
FAIL:  merge_tests.py 17: merge into missing must not break working copy
FAIL:  merge_tests.py 18: merge --dry-run adding a new file with props
FAIL:  merge_tests.py 19: merge binary files with common ancestry
FAIL:  merge_tests.py 20: merge with funny characters (issue #1905)
FAIL:  merge_tests.py 21: merge changes to keyword expansion property
FAIL:  merge_tests.py 22: merge prop change into deleted target
FAIL:  merge_tests.py 24: merge between branches (Issue #2222)
FAIL:  merge_tests.py 25: property merges don't overwrite existing prop-mods
FAIL:  merge_tests.py 26: property merge conflict even without local mods
FAIL:  merge_tests.py 27: undo, then redo a property merge
FAIL:  merge_tests.py 28: cherry-pick a dependent change, get conflict
FAIL:  merge_tests.py 29: merge a replacement of a file
FAIL:  merge_tests.py 31: merge a replacement of a file to mixed rev wc
FAIL:  merge_tests.py 32: merge an added dir on a deleted dir in target
FAIL:  merge_tests.py 33: ignore whitespace when merging
FAIL:  merge_tests.py 34: ignore eolstyle when merging
FAIL:  merge_tests.py 35: conflict from merge of add over versioned file
FAIL:  merge_tests.py 36: conflict markers should match the file's eol style
FAIL:  revert_tests.py 6: revert a merge replacement of file with history
FAIL:  stat_tests.py 22: status on conflicted added file
FAIL:  special_tests.py 7: merge symlink into file

Yet to delve for the cause of the failure.

With regards
Kamesh Jayachandran


-----Original Message-----
From: justin.erenkrantz <at> gmail.com on behalf of Justin Erenkrantz
Sent: Fri 12/29/2006 11:16 PM
To: Kamesh Jayachandran
Cc: SVN Dev
Subject: Re: Serf takes more time to complete the tests than dav

On 12/29/06, Justin Erenkrantz <justin <at> erenkrantz.com> wrote:
> I haven't had time to dig down and figure out why yet.  I may get to
> it this weekend, time permitting.

Actually, this might have been really trivial.

Kamesh: Please try out r1097 of serf.  This has a fix for being
smarter about writing headers.  This greatly reduces the amount of TCP
packets serf puts out.  If this helps, I'll cut a serf 0.1.1 with this
fix included.

Just for basic tests #1, it cut the captured network traffic from
~500KB down to ~140KB - bringing the number of packets almost
identical to ra_dav.  (I think loopback hosts are more sensitive to
this sort of thing, but reducing the overall number of packets is
generally a good thing!)

Here's what I have now:

basic tests with ra_dav:
real    2m15.188s
user    0m21.034s
sys     0m18.950s
(2.8MB of traffic)

basic tests with ra_serf (r1097 of serf):
real    2m14.056s
user    0m18.697s
sys     0m19.278s
(3.3MB of traffic)

basic tests with ra_serf (pre-r1097)
real    2m24.351s
user    0m18.817s
sys     0m19.923s
(12MB of traffic)

Thanks.  -- justin


Permalink | Reply | 3 comments |
headers
D.J. Heap | 1 Jan 2007 18:22
Picon

Re: svn trunk r22841: FAIL (win32-xp VS2005)

On 12/31/06, Branko Čibej <brane <at> xbc.nu> wrote:
[snip]
> Maybe win-tests.py should be doing the same thing with the SVN DLLs that
> it does with the APR DLLs -- copy them to the root of the test dir,
> instead of changing the path.
>

Hmm, that wouldn't help would it?  Or is Apache looking there for some
reason?  Maybe we need to copy the SVN Apache modules and all support
dll's to the same directory?

DJ
Permalink | Reply | 17 comments |

Gmane