headers
Ben Collins-Sussman | 1 Jun 2004 01:46
Favicon

Re: [PATCH] The blame speedup, second try

On Mon, 2004-05-31 at 15:26, Peter N. Lundblad wrote:

> I've reworked the patch, so that the file_rev_handler takes a delta stream
> instead of the name of a temporary file. Also, I created a repos function
> matching the RA layer one. libsvn_client/blame.c is a real mess currently.
> Obviously, I'll clean it up before you'll se its commited.
> 
> Any comments?

Question:  is 'svn blame' measurably faster with this optimization?  Or
is it impossible to measure right now, since you only have it working
with ra_local?
Permalink | Reply | 6 comments |
headers
Branko Čibej | 1 Jun 2004 04:40
Picon

Re: RFC: Hash dumps in sorted order

Julian Foad wrote:

> C. Michael Pilato wrote:
>
>> Greg Hudson <ghudson <at> MIT.EDU> writes:
>>
>>> Seriously, I'm just trying to keep the door open for the future.
>>> Branko's "path look up table" thread is what got me thinking about it,
>>> but (as I mentioned in that thread) I don't see any immediate big
>>> performance wins coming from speeding up single-path directory
>>> lookups.
>>
>>
>> Actually, it should improve the diff-ability of dumpfiles (and working
>> copy admin areas, for debuggability purposes), at the very least.
>> +1 on predictable behavior. :-)
>
>
> Fantastic!  Methinks now is the time to chip in with my patch to make
> Subversion's user-visible operations proceed in sorted order.  In
> particular, I want "svn status" output to be sorted (without piping it
> through a "sort" filter, because that removes streaminess) so that I
> can read it and find things in it (by eye) more easily, and "svn diff"
> output to be sorted so I can meaningfully compare one patch file with
> another similar one.  A separate thread will blink into existence.

Well, the easiest way to make the repository-side operations sorted is
by sorting the directories in the repo, and the easiest way to do that
is by putting them into a path-l^H^H^H^H^H^H er, sorted index... :-)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Greg Hudson | 1 Jun 2004 04:51
Picon
Favicon

Re: PATCH: Perform multi-file operations in sorted order

On Mon, 2004-05-31 at 18:34, Julian Foad wrote:
> I have as yet failed to get the hardest part working, which is sorting
> the combination of local and repository information for "svn diff
> -rX[:Y]" and "svn status --show-updates".  The crux of this seems to
> be sorting the various add/change/delete operations within
> subversion/libsvn_repos/reporter.c (delta_dirs), but when I try to do
> that various things fail.  It may be theoretically impossible but I do
> not yet see any reason why.  I may try that again and/or request help
> on it later, but, even without it, having local operations sorted
> seems very nice to me.

Well, it's possible, but it's not easy, so I'm not sure if it's worth
it.  There are two big cans of worms:

  #1: Instead of traversing the report information followed by the
target information followed by the source information, we have to
traverse the (sorted) source and target information at the same time as
the report (asking, at each step, which comes next lexically: a source
item, a target item, or a report item).  And we have to behave correctly
if the client's report isn't sorted (because the report could have come
from a 1.0 client).  (By "correctly" I mean we have to display all the
right output, but not necessarily in alphabetical order.)

  #2: Frequently, on the libsvn_wc side of things, the editor's
close_directory() handler will process everything the server didn't
mention.  For instance, "svn st -u" will (I presume) report on status
actions received from the server and then, when the directory is closed,
report on locally modified or added files not mentioned by the server
(and also recurse into subdirectories not mentioned by the server).  All
these editors would have to be changed to, each time the server mentions
(Continue reading)

Permalink | Reply | 5 comments |
headers
Greg Hudson | 1 Jun 2004 04:52
Picon
Favicon

Re: RFC: Hash dumps in sorted order

On Mon, 2004-05-31 at 22:40, Branko Čibej wrote:
> Well, the easiest way to make the repository-side operations sorted is
> by sorting the directories in the repo, and the easiest way to do that
> is by putting them into a path-l^H^H^H^H^H^H er, sorted index... :-)

Sorry, not even a little bit.  Sorting the result of
svn_fs_dir_entries() is the easiest part.
Permalink | Reply | 2 comments |
headers
Branko Čibej | 1 Jun 2004 04:56
Picon

Re: RFC: Hash dumps in sorted order

Greg Hudson wrote:

>On Mon, 2004-05-31 at 22:40, Branko Čibej wrote:
>  
>
>>Well, the easiest way to make the repository-side operations sorted is
>>by sorting the directories in the repo, and the easiest way to do that
>>is by putting them into a path-l^H^H^H^H^H^H er, sorted index... :-)
>>    
>>
>
>Sorry, not even a little bit.  Sorting the result of
>svn_fs_dir_entries() is the easiest part.
>  
>
But not streamy...

Aargh. We'll obviously go back and forth on this issue until somebody
(me?) actually implements the lookup table and comes up with numbers.
Let's drop it until then.

--

-- 
Brane Čibej   <brane <at> xbc.nu>   http://www.xbc.nu/brane/
Permalink | Reply | 1 comment |
headers
Greg Hudson | 1 Jun 2004 05:04
Picon
Favicon

Re: RFC: Hash dumps in sorted order

On Mon, 2004-05-31 at 22:56, Branko Čibej wrote:
> But not streamy...

We're essentially never streamy when it comes to directories, and
delta_dirs() is no exception (either in the old implementation or the
new one).  We read all the source and target directory entries into
hashes, iterate over the target hash, and look up corresponding entries
in the source hash.

So, you can chalk up streamy directory comparisons as a potential
benefit of the path lookup table (although simply writing out the
directories in sorted order might accomplish the same thing), but it's
irrelevant to producing sorted output.
Permalink | Reply | 0 comments |
headers
Wolfgang Schmiesing | 1 Jun 2004 11:05
Picon
Picon

servlet access to svn repository

Hi,

I'd like to view and control a repository located on my application server from a servlet located on my
webserver. The servlet should only be able to READ information and present it on the website. So all
working copies should remain on the application server.
Due to administrative issues I can only run the svnserve server on the backend at the moment.
Now:
Is it at all possible to implement (at least a subset of) subversion commands from a servlet? 
Which libraries are needed on the webserver to access the remote repository or do I need a full SVN
installation on the webserver?
I thought about calling some of the library functions via SWIG from within the servlet. Are there any
alternatives? 
I just don't know where to start.

cheers,

wolfgang
Permalink | Reply | 1 comment |
headers
Patrick Mayweg | 1 Jun 2004 11:40
Picon
Favicon

Re: servlet access to svn repository

Hi Wolfgang,
Wolfgang Schmiesing wrote:

>Hi,
>
>I'd like to view and control a repository located on my application server from a servlet located on my
webserver. The servlet should only be able to READ information and present it on the website. So all
working copies should remain on the application server.
>Due to administrative issues I can only run the svnserve server on the backend at the moment.
>Now:
>Is it at all possible to implement (at least a subset of) subversion commands from a servlet? 
>Which libraries are needed on the webserver to access the remote repository or do I need a full SVN
installation on the webserver?
>I thought about calling some of the library functions via SWIG from within the servlet. Are there any
alternatives? 
>I just don't know where to start.
>  
>
There is the javahl binding, which could be used for read access to the 
server as an alternative. It make the commands of the command line 
client available to java programms.

>
>cheers,
>
>wolfgang
>  
>
Patrick
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ben Collins-Sussman | 1 Jun 2004 14:34
Favicon

regarding issue 667: data loss??

I'm confused about the scope of this issue.  It was originally about
little annoyances here and there in dealing with case-insenstive
filesystems (OSX, NTFS).  But a month ago, SteveKing added a description
that makes the issue sound much more serious, followed by a even more
recent comment from Michael Bevin.  Both of these people are complaining
of data loss, which means P1 in my mind.  I'd like to bring this problem
into the spotlight for a moment.

SteveKing's description says:

"It seems that this issue has become a serious one for many windows
users. I'm getting reproducable reports from TSVN users who lost their
data because of this. There are some older text editors on windows who
automatically change the filename to all uppercase on saving.
example:
working copy with some files in it. One of those files is testfile.txt.
Edit testfile.txt and save it with an old editor
testfile.txt is now TESTFILE.TXT in the working copy.
do an 'svn up'
> Restored 'testfile.txt"
and the modifications on that file are gone! They got reverted during the 
update."

Can someone explain to me what's happening in this example?  I'm trying
to guess at what the editor and Subversion are doing.

When the editor saves the file as TESTFILE.TXT, that means that
testfile.txt is no longer present, right?  Because it's impossible for
those two files to exist simultaneously in the same directory, right? 
Then I'm guessing that 'svn up' does a case-sensitive comparison of
(Continue reading)

Permalink | Reply | 1254 comments |
headers
Julian Foad | 1 Jun 2004 15:07

Re: svn commit: r9916 - trunk/doc/book/book

sussman <at> tigris.org wrote:
> Author: sussman
> Date: Mon May 31 22:16:26 2004
> New Revision: 9916
> 
> Modified:
>    trunk/doc/book/book/ch03.xml
> Log:
> Slightly modified book patch from Eric Hanchrow <offby1 <at> blarg.net>:
> 
> * doc/book/book/ch03.xml:  show 'I' output in 'svn status' section.

Uh, the explanation below is as much confusing as it is helpful.

> Modified: trunk/doc/book/book/ch03.xml
> ==============================================================================
> --- trunk/doc/book/book/ch03.xml	(original)
> +++ trunk/doc/book/book/ch03.xml	Mon May 31 22:16:26 2004
>  <at>  <at>  -802,6 +802,7  <at>  <at> 
>  ?      foo.o               # svn doesn't manage foo.o
>  !      some_dir            # svn manages this, but it's either missing or incomplete
>  ~      qux                 # versioned as dir, but is file, or vice versa
> +I      .screenrc           # this file is ignored
>  A  +   moved_dir           # added with history of where it came from
>  M  +   moved_dir/README    # added with history and has local modifications
>  D      stuff/fish.c        # this file is scheduled for deletion
>  <at>  <at>  -912,6 +913,19  <at>  <at> 
>                  and created a directory in its place, without using the
>                  <command>svn delete</command> or <command>svn add</command>
>                  commands.</para>
(Continue reading)

Permalink | Reply | 3 comments |

Gmane