Re: Unstable test

On Wed, Feb 07, 2007 at 08:14:19AM -0500, Daniel Jacobowitz wrote:
> The attached patch fixes the only test failures in SVK 2.0.0 for me.
> The test depends on the order of files returned by the system
> readdir(); sometimes I get qz before qu, depending on the host and
> filesystem (e.g. RHEL4 ext3 qz is first, RHEL4 NFS qu is first).

Here's a better patch.

--

-- 
Daniel Jacobowitz
CodeSourcery

_______________________________________________
svk-devel mailing list
svk-devel <at> bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel

Re: smerge/pull with renames

Any more updates on this?

--jason

On Mar 28, 2007, at 3:50 PM, Chia-Liang Kao wrote:

> On 28/03/07, Jason Dillon <jason <at> planet57.com> wrote:
>> Is this related to the bits in the test which are marked as
>> "todo_skip 'not working', 5;" ?
>>
>> Will look into this further.  Not sure I understand how the .t files
>> really work or I would try to update them.  But I can probably get a
>> simple example with a bash script to reproduce.
>
> Nice guess, and that's why the tests are still marked as todo ;)  so
> they are still not passing but the tree is still buildable.
>
> Still working on it.  But glad to know you are keeping an eye on it.
> I will post updates on this.
>
> Cheers,
> CLK
> _______________________________________________
> svk-devel mailing list
> svk-devel <at> bestpractical.com
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel

_______________________________________________
svk-devel mailing list
svk-devel <at> bestpractical.com

Re: smerge/pull with renames

Can you see if the latest trunk work for you?

On 03/05/07, Jason Dillon <jason <at> planet57.com> wrote:
> Any more updates on this?

Cheers,
CLK
_______________________________________________
svk-devel mailing list
svk-devel <at> bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel

Re: File leak in performing large smerge

On 28/04/07, Wincent Colaiuta <win <at> wincent.com> wrote:
> > I was in the middle of a large smerge operation (over 200 revisions)
>
> Doh, forgot to post the details:
>
> svk, version v2.0.1 (using Subversion bindings 1.4.3)

What version of perl is your svk using?  Perl 5.8.0 has some problems
with svn's perl bindings about tied file handles.

Cheers,
CLK
_______________________________________________
svk-devel mailing list
svk-devel <at> bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel

Re: smerge/pull with renames

Yup, I'll give my tests another go.  Just didn't hear anything about  
it for a while... was curious if anymore bugs had been fixed.  I'll  
play with it again and report back.  Thanks 

--jason

On May 5, 2007, at 12:19 AM, Chia-Liang Kao wrote:

> Can you see if the latest trunk work for you?
>
> On 03/05/07, Jason Dillon <jason <at> planet57.com> wrote:
>> Any more updates on this?
>
> Cheers,
> CLK
> _______________________________________________
> svk-devel mailing list
> svk-devel <at> bestpractical.com
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel

_______________________________________________
svk-devel mailing list
svk-devel <at> bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel

Re: File leak in performing large smerge

El 5/5/2007, a las 9:22, Chia-Liang Kao escribió:

> On 28/04/07, Wincent Colaiuta <win <at> wincent.com> wrote:
>> > I was in the middle of a large smerge operation (over 200  
>> revisions)
>>
>> Doh, forgot to post the details:
>>
>> svk, version v2.0.1 (using Subversion bindings 1.4.3)
>
> What version of perl is your svk using?  Perl 5.8.0 has some problems
> with svn's perl bindings about tied file handles.

It's the stock Perl installed on Mac OS X 10.4.9 (Intel):

$ perl --version

This is perl, v5.8.6 built for darwin-thread-multi-2level
(with 3 registered patches, see perl -V for more detail)

$ uname -a
Darwin cuzco.local 8.9.1 Darwin Kernel Version 8.9.1: Thu Feb 22  
20:55:00 PST 2007; root:xnu-792.18.15~1/RELEASE_I386 i386 i386

$ svn --version
svn, version 1.4.3 (r23084)
    compiled Jan 26 2007, 12:55:56

Sorry for not providing this info with my original post... I was in  
too much of a hurry when I sent it!

Many add-s, rm-s, propset-s - how to avoid many store()s rewriting the config file?

Hi,

I want to keep a directory tree with 1000s of files under version 
control with svk.

I also want to keep a record of the file mode, uid and gid of the 
different files as properties with propset.

What I intended to do was to
#!/usr/bin/perl -w
use strict;
use SVK;
use SVK::XD;

and then look at the output of $svk->status("/dir/to/tree"). For each 
line beginning with /^\?/ $svk->add($file) and for each line /^\!/ 
$svk->rm($file) and then $svk->propset('mode', $mode, $file) and similar 
for uid and gid.

However, this takes *forever* - especially initially. Because after 
every operation, store() is called that does a YAML::DumpFile() on 
$SVKROOT/config and presumably a LoadFile() again right after. As config 
gets bigger, this takes longer and longer and longer.

Is there any way to only have it do *one* store - in the end when it is 
done, instead of the many, many stores in between?

As an experiment I just used YAML directly on the config file, and what 
took hours with $svk->???() took a second or two with YAML... But 
messing with the config file directly is, well, messy.

<>

--

-- 
cheers  thomasl

web : http://thomaslauer.com/start
_______________________________________________
svk-devel mailing list
svk-devel <at> bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel

svk 2.0.1, Win32 and locales

(Sorry for the empty mail I sent an hour or so ago: hit a key I
shouldn't have hit.)

I have used (or rather tested) SVK for the last two weeks in a small C
project. So far, things do look pretty good. Emboldened by this, I've
just decided to deploy a bigger project: a chaotic mixture of .doc and
.xls files (that's MS Office stuff) and a tree with my website contents,
text, binaries, warts and all.

The good news is that basically it works. The bad news is that there are
a few small, but annoying niggles which seem to be Win32 and/or locale
specific. I have some filenames (say "Tüt.txt") with [\x80-\xff]
characters in them. This is what I get when SVK tries to commit one of
these files: "Can't decode path as utf8." (The commit is aborted.)

The problem seems to arise in SVK's Util.pm, get_encoding(). This always
returns utf8 on my machine regardless of my locale or LANG settings. For
the time being I've patched get_encoding() so it returns a hard-coded
"iso-8859-1".

After that I once more tried the commit and now all files, including
those with accents etc., went through without a hitch: nice. Even nicer
is that almost everything else works as well: revert, cat, log... all
that looks good, even with filenames with non-Ascii characters in them.

However, what doesn't work *at all* are the update and diff commands
(perhaps there are others). I get a blunt "Can't encode path as
iso-8859-1." with update and a not very helpful "Invalid argument: Safe
data '--- T' was followed by non-ASCII byte 195: unable to convert
to/from UTF-8" when doing a diff.

Re: svk 2.0.1, Win32 and locales

Hi,

Thanks for reporting this.

On 09/05/07, Thomas Lauer <thomas.lauer <at> virgin.net> wrote:
> 1) Why won't get_encoding() return the right encoding on Win32? (I have
> the current version of Win32::Console.)

Can you see what this prints?

perl -MWin32::Console -le 'print Win32::Console::OutputCP()'

Cheers,
CLK
_______________________________________________
svk-devel mailing list
svk-devel <at> bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel