Re: [PATCH] vc-svn: vc-merge, avoid status checks

>> Indeed, VC lacks a notion of "file with unresolved conflicts".  Maybe
>> we should add it to the possible return values of vc-state.
> Yes, or it could perhaps be handled as another vc property of the
> file.  It might be nice to have a "conflicted" flag in the modeline.

I don't think it needs to be a property.  After all, if a file is
conflicted, it obviously will be neither up-to-date nor needs-patch
not needs-merge (nor locked, of course), so it makes sense to
have it as a state.

> I think it can be done with no need for an option:
>   if people want updates, they can (with this patch) run vc-merge.
>   if we try to commit and we're not uptodate, we can detect that as
>   vc-cvs does.

That's what I made possible for vc-cvs.el (which originally had no
way to "stay local" and was thus unusable with slow repositories).

But it turns out that some people really enjoy being told right away
that the commit will fail (obviously their repository is zippy), so
Andre Spiegel introduced the vc-cvs-stay-local configuration variable.

I think it makes sense to have a vc-stay-local variable and have
both vc-cvs and vc-cvn obey it (while maybe still having their own
vc-foo-stay-local).

>> Good to hear.  This is a serious problem with CVS where recovering the
>> `ancestor' and the `other' can be difficult.  Now I think this is
>> a good argument for re-introducing a way to call ediff from VC
>> (in the current CVS code for Emacs, this has been removed and VC

Re: [PATCH] Compressed streams (take 2)

Eric Dorland <eric.dorland <at> mail.mcgill.ca> writes:

> * Philip Martin (philip <at> codematters.co.uk) wrote:
> > I agree, we just want to test the Subversion code.  However, rather
> > than just hardcoding a chunk of data, I would use a simple algorithm
> > to generate some bytes.  It doesn't really matter what you use, a
> > simple 0, 1, 2, ..., 253, 254, 255, 245, 253, ... 3, 2, 1, 0 repeated
> > would probably do, or how about 256 bytes incrementing in steps of 1,
> > 256 bytes incrementing in steps of 3, 256 bytes incrementing in steps
> > of 5, ...
> 
> Ok, how is this better than just the hardcoded data?

I don't know if it is significantly better, it's just the way I would
have done it.

> If the data I
> generate the data in too regular a fashion, it's going to compress too
> well and defeat the purpose of the test.

The test can check the length of the compressed data, if it's too
short it can do something, fail or generate more data.

> > However you do it, the algorithm should generate an amount of data
> > based on the value of ZBUFFER_SIZE.  Is ZBUFFER_SIZE something to do
> > with the uncompressed data, or the compressed data?
> 
> It relates to the compressed data. It's the amount of compressed data
> a read will pull in at a time, whenever a read is done on a compressed
> stream. I tested the hardcoded data so I know it compresses to

Re: hang during tests?

Michael Price <mprice <at> atl.lmco.com> writes:

> It happens every now and then for me on FreeBSD as well so I doubt it
> has anything to do with gentoo kernel mods.

Have you ever investigated?  Where does it hang?  If you don't
investigate it may not get fixed...

--

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe <at> subversion.tigris.org
For additional commands, e-mail: dev-help <at> subversion.tigris.org

Re: [PATCH] Compressed streams (take 2)

Hi Philip,

* Philip Martin (philip <at> codematters.co.uk) wrote:
> Eric Dorland <eric.dorland <at> mail.mcgill.ca> writes:
> 
> > * Philip Martin (philip <at> codematters.co.uk) wrote:
> > > I agree, we just want to test the Subversion code.  However, rather
> > > than just hardcoding a chunk of data, I would use a simple algorithm
> > > to generate some bytes.  It doesn't really matter what you use, a
> > > simple 0, 1, 2, ..., 253, 254, 255, 245, 253, ... 3, 2, 1, 0 repeated
> > > would probably do, or how about 256 bytes incrementing in steps of 1,
> > > 256 bytes incrementing in steps of 3, 256 bytes incrementing in steps
> > > of 5, ...
> > 
> > Ok, how is this better than just the hardcoded data?
> 
> I don't know if it is significantly better, it's just the way I would
> have done it.

Ok :) It's probably more flexible that way, but I don't think it
matters that much.

> > If the data I
> > generate the data in too regular a fashion, it's going to compress too
> > well and defeat the purpose of the test.
> 
> The test can check the length of the compressed data, if it's too
> short it can do something, fail or generate more data.

Yes, that's true. But again care is needed, because if the generated

SOLVED: Re: Problem with the svn python bindings

Hi,

Change # 5502 changed the interface to svn_fs_file_length() without changing 
fs.py in the python bindings.

The latest tip of subversion crashes when I run cvs2svn.py.  Not sure why, 
older versions dont segfault.  Also, viewcvs segfaults with the latest tip.  
I think I'll be syncing backwards to 5501 to avoid these problems.

Regards,
-ryan

ryan <ryan <at> netidea.com> said: 

> Hi,
> 
> I've taken most of the weekend to install Subversion.  Several problems and
> solutions:
> 1. if you want to install into /usr/local/stow instead of plain /usr/local,
> you cannot use make install to install the subprojects such as apr,
> apr-util, neon, db4.  Do those seperately instead.  Or use the debian
> packages for everything but neon.
> 2. While make install, do this first:
> Export LD_LIBRARY_PATH=/usr/local/stow/subversion/lib
> Export LIBRARY_PATH=/usr/local/stow/subversion/lib
> 
> This worked for me.
> 
> 3. make swig-py

Re: [PATCH] Compressed streams (take 2)

Eric Dorland <eric.dorland <at> mail.mcgill.ca> writes:

> It was basically arbitrary. I picked something that wasn't too small
> and that would likely be the size of a page, or some constant multiple
> of the size of a page.

That's the sort of information that should go in a comment beside the
constant.

> I'm sure different sizes would yield different
> performance characteristics in different situations (eg a bigger
> buffer would be better for larger reads, but penalize smaller ones). I
> don't think it really matters too much, since I think the IO system
> under Linux and other Unices would cache things enough to make it
> pretty irrelevant what I choose (as long as it's not too insane).

APR will also provides buffering of files if requested.

> I could even make the buffer dynamic in size, with some heuristic
> based on the amount of data the user wants to read it.

I'm not sure a heuristic is a good idea, mainly because I don't know
how to evaluate it.  What about a buffer size argument to
svn_stream_compressed?  Is that a good idea?  Perhaps with a #define
(your 4096) for a default value.

> It's probably
> not worth it though. But hey, if it gets my patch in, I'll do it :)

I'm not trying to be awkward, I'm just trying to understand the patch

Re: Thoughts on libsvn_auth

Justin Erenkrantz <justin <at> erenkrantz.com> writes:

> For auth-read/auth-write, you won't know initially what the UUID
> will be since you can't look at the repository until you are
> authorized.  You'd just have to prompt in all cases.

That doesn't address Manoj's "realm" problem: for which svn:external
URL is this prompt?

--

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe <at> subversion.tigris.org
For additional commands, e-mail: dev-help <at> subversion.tigris.org

Re: 89 (+1) issues left to reach svn 1.0

On Mon, Mar 31, 2003 at 10:55:32PM +0000, Gareth McCaughan wrote:
> On Monday 31 March 2003 1:22 pm, "solo turn" wrote:
> > defec: 57 (+2)
> > enhan: 16 (0)
> > featu:  3 (-1)
> > task :  8 (-1)
> > patch:  5 (0)
> 
> Something's broken. (+2) + (-1) + (-1) != (+1).
> 

*That's* the +1!

--ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe <at> subversion.tigris.org
For additional commands, e-mail: dev-help <at> subversion.tigris.org

(forw) Re: [PATCH] Compressed streams (take 2)

Sorry, meant to send this to the list.

-- 
Eric Dorland <eric.dorland <at> mail.mcgill.ca>
ICQ: #61138586, Jabber: hooty <at> jabber.com
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
------END GEEK CODE BLOCK------

From: Eric Dorland <eric.dorland <at> mail.mcgill.ca>
Subject: Re: [PATCH] Compressed streams (take 2)
Date: 2003-04-01 00:59:43 GMT

* Philip Martin (philip <at> codematters.co.uk) wrote:
> Eric Dorland <eric.dorland <at> mail.mcgill.ca> writes:
> 
> > It was basically arbitrary. I picked something that wasn't too small
> > and that would likely be the size of a page, or some constant multiple
> > of the size of a page.
> 

Re: Storing unversioned files in a repository.

On Mon, Mar 31, 2003 at 01:35:25PM +0200, brane <at> xbc.nu wrote:
>...
> > I admit that such use-cases are very rare and that it does not make much
> > sense to implement it before-1.0. But you can not say that there are _no_
> > such cases.
> 
> What I'm saying is that a version control tool should be just that -- a version
> control tool. Not a repository for unversioned files.

Brane,

People have all kinds of reasons for requesting certain types of
functionality. Just because you disagree doesn't mean their use case is
invalid. You might not agree to make the changes to support that use case,
but please go a bit easier when you question what people are trying to do.
It is entirely possible there is a lot more thought and reasoning behind
their query that they omitted for brevity. If you out-of-hand reject their
use case, after they've applied a lot of thought, can come off as "man, that
guy is being a jerk and hasn't listened to what I'm talking about." The
person making a request sees a rejection as irrational since (in their mind)
they have a perfectly valid proposal with plenty of supporting rationale.

Personally, I can see unversioned files as a very handy feature. Yes,
Subversion is a version control system, but an unversioned file type is a
minor step to a great content management / publishing tool. I'm certainly
not about to reject it out of hand. I'd be quite curious what it would
actually take to implement such a thing.

Cheers,
-g