Nabble - Subversion Dev

Re: Turn abs-paths into rel-paths for display

2009-12-07T11:14:52Z

Hyrum K. Wright wrote:

> On Dec 4, 2009, at 6:34 PM, Julian Foad wrote:
>
> > Daniel Näslund wrote (on IRC):
> >> Have we agreed on a way to turn abspaths into paths when displaying
> >> them to users?
> >
> > The last I heard was Kannan (I think) on email saying something like,
> > "So we want a function to do this, but do we also need a data structure
> > to do this?" I replied something like, "We need a conversion function,
> > and we need a way to pass the base path to that function."

It looks like we already have suitable functions -
svn_dirent_skip_ancestor() etc.:

/** Returns the relative path part of @a dirent2 that is below @a dirent1,
* or just "" iif @a dirent1 is equal to @a dirent2. If @a dirent2 is not
* below @a path1, return @a dirent2 completely.
[...]

- Julian

> > I'm sure either of you is very welcome to tackle it.
>
> Sounds like issue #3464: http://subversion.tigris.org/issues/show_bug.cgi?id=3464
>
> -Hyrum
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427464
>
> Please start new threads on the <dev@...> mailing list.
> To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427908

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

Re: Turn abs-paths into rel-paths for display

2009-12-05T07:41:17Z

On Dec 4, 2009, at 6:34 PM, Julian Foad wrote:

> Daniel Näslund wrote (on IRC):
>> Have we agreed on a way to turn abspaths into paths when displaying
>> them to users?
>
> The last I heard was Kannan (I think) on email saying something like,
> "So we want a function to do this, but do we also need a data structure
> to do this?" I replied something like, "We need a conversion function,
> and we need a way to pass the base path to that function."
>
> I'm sure either of you is very welcome to tackle it.

Sounds like issue #3464: http://subversion.tigris.org/issues/show_bug.cgi?id=3464

-Hyrum

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427464

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

Re: [PATCH] gpg-agent support

2009-12-05T06:58:45Z

Thanks, Gavin.

I am still working on it. I applied some of the suggestions that Philip
made, where I have it running at work (the reason I developed the
feature to begin with).

It might be after Christmas before I get around to cleaning it up and
re-submitting it, though. The feature is written against 1.6.5 at work,
so I need to bring that home and regenerate the patch against the trunk.
Not a big task, but something that I probably won't have time for
between working, buying Christmas for nine kids (two with families of
their own) and visiting extended families.

Thanks for the encouragement, though!

-Dan

On Fri, 2009-12-04 at 11:45 +1100, Gavin Baumanis wrote:

> Hi Dan,
>
> Just thought I would chase up you patch proposal and see if you're still working on it, or not?
> Also - While I might be stating the obvious, please do not hesitate to ask for any help you might need.
>
> Gavin.
>
>
> On 26/11/2009, at 23:55 , Philip Martin wrote:
>
> > Dan Engel <dengel@...> writes:
> >
> >> Thanks for the comments, Philip.
> >>
> >> So, what's the protocol? Do I fix things up per suggestions, re-diff
> >> against the (by then) latest trunk, and re-submit?
> >
> > Yes, please.
> >
> > --
> > Philip
> >
> > ------------------------------------------------------
> > http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2424590
> >
> > Please start new threads on the <dev@...> mailing list.
> > To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2426868
>
> Please start new threads on the <dev@...> mailing list.
> To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427457

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

signature.asc (205 bytes) Download Attachment

RE: [PATCH] incoming copy of locally modified file(under repo_root) is not receiving the local modification

2009-12-04T18:44:53Z

RE: [PATCH] incoming copy of locally modified file(under repo_root) is not receiving the local modification

Committed in r887484.

With regards
Kamesh Jayachandran

-----Original Message-----
From: Kamesh Jayachandran [kamesh@...]
Sent: Sat 12/5/2009 12:36 AM
To: Julian Foad
Cc: dev@...
Subject: RE: [PATCH] incoming copy of locally modified file(under repo_root) is not receiving the local modification

Hi Julian,

Thanks for the review. I have some problem in committing via my ASF account(Sent a mail to infrastructure@...) will commit after that.

Kannan Rengarajan was working on writing a testcase for this so I leave it to him.

With regards
Kamesh Jayachandran

-----Original Message-----
From: Julian Foad [julianfoad@...]
Sent: Fri 12/4/2009 11:56 PM
To: Kamesh Jayachandran
Cc: dev@...
Subject: Re: [PATCH] incoming copy of locally modified file(under repo_root) is not receiving the local modification

Kamesh Jayachandran wrote:
> I observed the following bug when I was working with the file under repo
> root.
[...]
> $svnadmin create repo
> $svn co file://`pwd`/repo wc
> $cd wc
> $echo "I am test.c" >test.c
> $svn add test.c
> $svn ci -m "log"
> $svn mv test.c test2.c
> $svn ci -m "refactor"
> $cd ..
> $svn co -r1 file://`pwd`/repo wc2
> $cd wc2
> $echo "modified" >>test.c
>
>
> $svn up
>
> The above svn update is not adding the 'modified' change to test2.c.
>
> Everything works fine if the files are *not* directly under repo root.

That looks like a good catch. Thanks.

Please could you add the test scenario into one of the regression tests?
If you could, that would be very helpful.

> Attached patch fixes it.
>
> I ran test against ra_local, *no* failure with this patch. Hope this fix
> is independent of ra layer and hence sending it without testing against
> each layer.
>
> If there are no objections will commit it by tomorrow.

> [[[
> incoming copy of locally modified file(under repo_root) is not
> receiving the
> local modification.
> * subversion/libsvn_wc/update_editor.c
> (locate_copyfrom): No need of early return for files under
> repo_root.
> ]]]

Please could you try to make the log message a bit clearer. The first
sentence needs the word "update" in it. The details should say what
behaviour you changed. ("No need..." just sounds like something was
being done that didn't make any difference.) Maybe something like:

[[[
Fix a bug in which "update" did not preserve the local changes in
a file when the incoming change is a simple rename, if the file was
directly under the repository root. If the file was not immediately
under the root, it did.

There is a test case in the email thread
<http://...>.

* subversion/libsvn_wc/update_editor.c
(locate_copyfrom): Remove an erroneous early return.
]]]

Thanks.
- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427172

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

Re: [PATCH][RFC] allow local file:// URLs for svnadmin

2009-12-04T16:36:47Z

David Glasser wrote:
> Another difference between RA URLs and repos filesystem paths is that
> RA URLs can contain directories inside the repository.
>
> So you'd have to figure out the semantics there. If somebody
> specifies file:///path/to/repos/then/subdir, is it equivalent to
> path/to/repos? Or an error? Either way is likely to be confusing to
> somebody.

That's a good additional point. Thanks.

- Julian

> (I'm generally in the "not a good idea" camp here.)
>
> --dave

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427302

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

Turn abs-paths into rel-paths for display

2009-12-04T16:34:44Z

Daniel Näslund wrote (on IRC):
> Have we agreed on a way to turn abspaths into paths when displaying
> them to users?

The last I heard was Kannan (I think) on email saying something like,
"So we want a function to do this, but do we also need a data structure
to do this?" I replied something like, "We need a conversion function,
and we need a way to pass the base path to that function."

I'm sure either of you is very welcome to tackle it.

- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427301

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

Re: [PATCH][RFC] allow local file:// URLs for svnadmin

2009-12-04T16:22:26Z

Another difference between RA URLs and repos filesystem paths is that
RA URLs can contain directories inside the repository.

So you'd have to figure out the semantics there. If somebody
specifies file:///path/to/repos/then/subdir, is it equivalent to
path/to/repos? Or an error? Either way is likely to be confusing to
somebody.

(I'm generally in the "not a good idea" camp here.)

--dave

On Fri, Dec 4, 2009 at 6:35 AM, Vincent Legoll <vincent.legoll@...> wrote:

> Hello,
>
> would such kind of patch be acceptable or is this useless ?
>
> I think there's nothing preventing svnadmin to accept local
> file:// URLs as repository location parameter. So why not ?
>
> The attached patch, is probably wrong (you tell me) as my
> C is a bit rusty, but should show the intended change...
>
> Comments, reviews, flames, etc... All gladly accepted.
>
> If this is deemed useful, I'll especially would like directions
> on how to improve the patch to make it suitable for a real
> submission...
>
> --
> Vincent Legoll
>
> ###################### Inline ########################
>
> --- a/main.c
> +++ b/main.c
> @@ -133,6 +133,15 @@ parse_local_repos_path(apr_getopt_t *os,
> }
> else if (svn_path_is_url(*repos_path))
> {
> + #define URL_LOCAL_FILE_PREFIX "file://"
> + if (strncmp(*repos_path, URL_LOCAL_FILE_PREFIX,
> + strlen(URL_LOCAL_FILE_PREFIX)))
> + {
> + *repos_path = svn_dirent_internal_style(*repos_path +
> + strlen(URL_LOCAL_FILE_PREFIX), pool);
> + return SVN_NO_ERROR;
> + }
> +
> return svn_error_createf(SVN_ERR_CL_ARG_PARSING_ERROR, NULL,
> _("'%s' is an URL when it should be a path"),
> *repos_path);
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427043
>
> Please start new threads on the <dev@...> mailing list.
> To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

--
glasser@... | langtonlabs.org | flickr.com/photos/glasser/

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427298

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

RE: svnsync large files

2009-12-04T16:09:40Z

Bitts, Daniel wrote:
> Nothing is set in the config file.
> Any suggestions where to look for relevant Apache settings?

No idea. Google?

> Here's the svnsync --version output, doesn't look like I have serf:

Thanks for the extra info. I'm glad we can rule out Serf. It all helps
to paint the picture.

- Julian

> svnsync, version 1.6.6 (r40053)
> compiled Oct 22 2009, 09:02:24
>
> Copyright (C) 2000-2009 CollabNet.
> Subversion is open source software, see http://subversion.tigris.org/
> This product includes software developed by CollabNet (http://www.Collab.Net/).
>
> The following repository access (RA) modules are available:
>
> * ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
> - handles 'http' scheme
> - handles 'https' scheme
> * ra_svn : Module for accessing a repository using the svn network protocol.
> - with Cyrus SASL authentication
> - handles 'svn' scheme
> * ra_local : Module for accessing a repository on local disk.
> - handles 'file' scheme
>
>
> Thanks!

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427295

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

RE: [PATCH] incoming copy of locally modified file(under repo_root) is not receiving the local modification

2009-12-04T11:06:51Z

RE: [PATCH] incoming copy of locally modified file(under repo_root) is not receiving the local modification

Hi Julian,

Thanks for the review. I have some problem in committing via my ASF account(Sent a mail to infrastructure@...) will commit after that.

Kannan Rengarajan was working on writing a testcase for this so I leave it to him.

With regards
Kamesh Jayachandran

-----Original Message-----
From: Julian Foad [julianfoad@...]
Sent: Fri 12/4/2009 11:56 PM
To: Kamesh Jayachandran
Cc: dev@...
Subject: Re: [PATCH] incoming copy of locally modified file(under repo_root) is not receiving the local modification

Kamesh Jayachandran wrote:
> I observed the following bug when I was working with the file under repo
> root.
[...]
> $svnadmin create repo
> $svn co file://`pwd`/repo wc
> $cd wc
> $echo "I am test.c" >test.c
> $svn add test.c
> $svn ci -m "log"
> $svn mv test.c test2.c
> $svn ci -m "refactor"
> $cd ..
> $svn co -r1 file://`pwd`/repo wc2
> $cd wc2
> $echo "modified" >>test.c
>
>
> $svn up
>
> The above svn update is not adding the 'modified' change to test2.c.
>
> Everything works fine if the files are *not* directly under repo root.

That looks like a good catch. Thanks.

Please could you add the test scenario into one of the regression tests?
If you could, that would be very helpful.

> Attached patch fixes it.
>
> I ran test against ra_local, *no* failure with this patch. Hope this fix
> is independent of ra layer and hence sending it without testing against
> each layer.
>
> If there are no objections will commit it by tomorrow.

> [[[
> incoming copy of locally modified file(under repo_root) is not
> receiving the
> local modification.
> * subversion/libsvn_wc/update_editor.c
> (locate_copyfrom): No need of early return for files under
> repo_root.
> ]]]

Please could you try to make the log message a bit clearer. The first
sentence needs the word "update" in it. The details should say what
behaviour you changed. ("No need..." just sounds like something was
being done that didn't make any difference.) Maybe something like:

[[[
Fix a bug in which "update" did not preserve the local changes in
a file when the incoming change is a simple rename, if the file was
directly under the repository root. If the file was not immediately
under the root, it did.

There is a test case in the email thread
<http://...>.

* subversion/libsvn_wc/update_editor.c
(locate_copyfrom): Remove an erroneous early return.
]]]

Thanks.
- Julian

RE: svnsync large files

2009-12-04T10:36:22Z

Julian,

Nothing is set in the config file.
Any suggestions where to look for relevant Apache settings?

Here's the svnsync --version output, doesn't look like I have serf:

svnsync, version 1.6.6 (r40053)
compiled Oct 22 2009, 09:02:24

Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme

Thanks!

Dan Bitts
Senior Network Engineer
General Dynamics
7021 Harbour View Blvd STE 102
Suffolk, VA 23435
Tel: (757) 483-2250 ext 208
Cel: (757) 748-3510
Fax: (757) 483-2265
dan.bitts@...
http://www.gdit.com

-----Original Message-----
From: Julian Foad [mailto:julianfoad@...]
Sent: Thursday, December 03, 2009 8:33 AM
To: Bitts, Daniel
Cc: dev@...
Subject: RE: svnsync large files

On Wed, 2009-12-02, Bitts, Daniel wrote:

> Julian,
>
> Nice script.
>
> I found replication file: to file: worked fine,
> https: to https: same server worked fine
> https: to https: over WAN fails with:
>
> svnsync: REPORT of 'https://master.vb.inside/mastersvn': Could not
> read response body: Secure connection truncated
> (https://master.vb.inside)

Ah, so now you show us the error message :-)

> The slave was https://slave.suffolk.inside/slavesvn, and svnsync was
> executed on the master server.
>
> It's looking more like an Apache issue than an SVN issue, but still is
> puzzling because users are regularly committing large files into the
> master over the WAN link from the slave site.

Yes. Perhaps you should be looking for timeouts or data transfer limits
in the Apache config. (I know very little about Apache config.)

Is your "svnsync" process using the Neon or the Serf library to make its
HTTP connections, do you know? This might make a difference. We can find
out from the output of "svnsync --version" plus any "http-library"
option in the "~/.subversion/config" file of the home directory of the
user account under which "svnsync" runs.

Can you try using the other one (Neon or Serf), if "svnsync --version"
indicates it supports both?

- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427152

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

Re: [PATCH] incoming copy of locally modified file(under repo_root) is not receiving the local modification

2009-12-04T10:26:53Z

Kamesh Jayachandran wrote:
> I observed the following bug when I was working with the file under repo
> root.
[...]

> $svnadmin create repo
> $svn co file://`pwd`/repo wc
> $cd wc
> $echo "I am test.c" >test.c
> $svn add test.c
> $svn ci -m "log"
> $svn mv test.c test2.c
> $svn ci -m "refactor"
> $cd ..
> $svn co -r1 file://`pwd`/repo wc2
> $cd wc2
> $echo "modified" >>test.c
>
>
> $svn up
>
> The above svn update is not adding the 'modified' change to test2.c.
>
> Everything works fine if the files are *not* directly under repo root.

That looks like a good catch. Thanks.

Please could you add the test scenario into one of the regression tests?
If you could, that would be very helpful.

> Attached patch fixes it.
>
> I ran test against ra_local, *no* failure with this patch. Hope this fix
> is independent of ra layer and hence sending it without testing against
> each layer.
>
> If there are no objections will commit it by tomorrow.

> [[[
> incoming copy of locally modified file(under repo_root) is not
> receiving the
> local modification.
> * subversion/libsvn_wc/update_editor.c
> (locate_copyfrom): No need of early return for files under
> repo_root.
> ]]]

Please could you try to make the log message a bit clearer. The first
sentence needs the word "update" in it. The details should say what
behaviour you changed. ("No need..." just sounds like something was
being done that didn't make any difference.) Maybe something like:

[[[
Fix a bug in which "update" did not preserve the local changes in
a file when the incoming change is a simple rename, if the file was
directly under the repository root. If the file was not immediately
under the root, it did.

There is a test case in the email thread
<http://...>.

* subversion/libsvn_wc/update_editor.c
(locate_copyfrom): Remove an erroneous early return.
]]]

Thanks.
- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427146

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

Re: [PATCH][RFC] allow local file:// URLs for svnadmin

2009-12-04T10:23:36Z

Julian Foad wrote on Fri, 4 Dec 2009 at 18:16 -0000:

> Daniel Shahaf wrote:
> > Philip Martin wrote on Fri, 4 Dec 2009 at 15:51 -0000:
> > > Julian Foad <julianfoad@...> writes:
> > >
> > > > Vincent Legoll wrote:
> > > >> I think there's nothing preventing svnadmin to accept local
> > > >> file:// URLs as repository location parameter. So why not ?
> > >
> > > I think it's a bad idea because svnadmin doesn't use the RA layer.
> >
> > That's my initial reaction as well. Nowhere do we accept file:/// URLs
> > instead of paths: not in the API, not in svn (you can't say
> > "svn info file://path/to/wc"), etc.
>
> Spurious analogy. We're not talking about accepting URLs to WCs, only to
> repositories.

I was in an "accept a file:// URL as an alias for the path it points to" mood.

> The converse comparison is: nowhere do we not accept a URL
> to refer to a repository, except currently in svnadmin/svnlook. (Sure,
> there's the "not a general RA access" argument, etc. to consider, and
> I'm not fighting for accepting it, just responding to your statement.)
>

In general, 'svn' mirrors the client API and 'svnadmin' mirrors the
repos API. If we want svnadmin to accept file:// URLs, shouldn't
svn_repos_open() accept them too?

(I'm not saying it shouldn't; I'm saying that, if svnadmin is extended,
we may extend the repos API in the same manner.)

> - Julian
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427139
>
> Please start new threads on the <dev@...> mailing list.
> To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427144

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

Re: [PATCH][RFC] allow local file:// URLs for svnadmin

2009-12-04T10:16:52Z

Daniel Shahaf wrote:

> Philip Martin wrote on Fri, 4 Dec 2009 at 15:51 -0000:
> > Julian Foad <julianfoad@...> writes:
> >
> > > Vincent Legoll wrote:
> > >> I think there's nothing preventing svnadmin to accept local
> > >> file:// URLs as repository location parameter. So why not ?
> >
> > I think it's a bad idea because svnadmin doesn't use the RA layer.
>
> That's my initial reaction as well. Nowhere do we accept file:/// URLs
> instead of paths: not in the API, not in svn (you can't say
> "svn info file://path/to/wc"), etc.

Spurious analogy. We're not talking about accepting URLs to WCs, only to
repositories. The converse comparison is: nowhere do we not accept a URL
to refer to a repository, except currently in svnadmin/svnlook. (Sure,
there's the "not a general RA access" argument, etc. to consider, and
I'm not fighting for accepting it, just responding to your statement.)

- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427139

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

Re: [PATCH][RFC] allow local file:// URLs for svnadmin

2009-12-04T10:06:26Z

Philip Martin wrote on Fri, 4 Dec 2009 at 15:51 -0000:
> Julian Foad <julianfoad@...> writes:
>
> > Vincent Legoll wrote:
> >> I think there's nothing preventing svnadmin to accept local
> >> file:// URLs as repository location parameter. So why not ?
>
> I think it's a bad idea because svnadmin doesn't use the RA layer.

That's my initial reaction as well. Nowhere do we accept file:/// URLs
instead of paths: not in the API, not in svn (you can't say
"svn info file://path/to/wc"), etc.

Daniel

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427134

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

[PATCH] incoming copy of locally modified file(under repo_root) is not receiving the local modification

2009-12-04T08:24:44Z

Hi All,

I observed the following bug when I was working with the file under repo
root.

$svnadmin create repo
$svn co file://`pwd`/repo wc
$cd wc
$echo "I am test.c" >test.c
$svn add test.c
$svn ci -m "log"
$svn mv test.c test2.c
$svn ci -m "refactor"
$cd ..
$svn co -r1 file://`pwd`/repo wc2
$cd wc2
$echo "modified" >>test.c

$svn up

The above svn update is not adding the 'modified' change to test2.c.

Everything works fine if the files are *not* directly under repo root.

Attached patch fixes it.

I ran test against ra_local, *no* failure with this patch. Hope this fix
is independent of ra layer and hence sending it without testing against
each layer.

If there are no objections will commit it by tomorrow.

With regards
Kamesh Jayachandran

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427104

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.
Index: subversion/libsvn_wc/update_editor.c
===================================================================
--- subversion/libsvn_wc/update_editor.c (revision 887212)
+++ subversion/libsvn_wc/update_editor.c (working copy)
@@ -3346,9 +3346,6 @@
ancestor_relpath = svn_relpath_get_longest_ancestor(dir_repos_relpath,
copyfrom_relpath,
scratch_pool);
- if (strlen(ancestor_relpath) == 0)
- return SVN_NO_ERROR;
-
/* Move 'up' the working copy to what ought to be the common ancestor dir. */
levels_up = svn_path_component_count(dir_repos_relpath)
- svn_path_component_count(ancestor_relpath);

[[[
incoming copy of locally modified file(under repo_root) is not receiving the
local modification.
* subversion/libsvn_wc/update_editor.c
(locate_copyfrom): No need of early return for files under repo_root.
]]]

Re: [PATCH][RFC] allow local file:// URLs for svnadmin

2009-12-04T08:19:45Z

C. Michael Pilato wrote:

> Hyrum K. Wright wrote:
> > My initial reaction is about consistency. I can't think of any place we
> > accept URLs as parameters to svnadmin, and I'm really hesitant to start
> > doing so. In the command-line client, when we say "URL" we mean *any*
> > well-formed URL, not just those with a specific access method. Changing
> > that meaning on any of the command-line tools is inconsistent, and should
> > be avoided.
>
> I'm a big fan of consistency. It's good for users. It's good for
> developers. It's great for parents. And drummers.

Me, too, as you well know, but it's not simply "consistency", it's
"consistency of <what?>". Your consistency is different from mine.

> I too, oppose this
> change, for the reasons Hyrum has so pleasantly stated.

I see your side too... and though there are merits in both sides, I
guess I'm coming around to the "leave it alone" point of view now.
Sorry, Vincent.

- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427097

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

Re: [PATCH][RFC] allow local file:// URLs for svnadmin

2009-12-04T07:51:46Z

Julian Foad <julianfoad@...> writes:

> Vincent Legoll wrote:
>> I think there's nothing preventing svnadmin to accept local
>> file:// URLs as repository location parameter. So why not ?

I think it's a bad idea because svnadmin doesn't use the RA layer.
Adding this will create the false expectation that all RA protocols
should work.

> If you want to do this, remember that converting a URL to a local path
> is not as simple as stripping off a prefix: there are at least two
> different prefixes (file://localhost as well), and you have to un-escape
> the URL escaping.

The client allows one to use file://localhost:port as well (although
that might be a bug).

--
Philip

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427085

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

Re: [PATCH][RFC] allow local file:// URLs for svnadmin

2009-12-04T07:36:10Z

Hyrum K. Wright wrote:

> On Dec 4, 2009, at 6:50 AM, Julian Foad wrote:
>
>> Vincent Legoll wrote:
>>> Hello,
>>>
>>> would such kind of patch be acceptable or is this useless ?
>>>
>>> I think there's nothing preventing svnadmin to accept local file://
>>> URLs as repository location parameter. So why not ?
>> Let me ask a different question: Why? (We don't add features just
>> because we can, we add them because they are useful enough to be worth
>> the maintenance.)
>>
>> I can think of a reason: it could be handy to copying URLs between
>> "svn" and "svnlook" and "svnadmin" commands. Is that your reason? Is
>> there any stronger reason? Would you add it to svnlook as well?
>>
>> If you want to do this, remember that converting a URL to a local path
>> is not as simple as stripping off a prefix: there are at least two
>> different prefixes (file://localhost as well), and you have to
>> un-escape the URL escaping.
>
> My initial reaction is about consistency. I can't think of any place we
> accept URLs as parameters to svnadmin, and I'm really hesitant to start
> doing so. In the command-line client, when we say "URL" we mean *any*
> well-formed URL, not just those with a specific access method. Changing
> that meaning on any of the command-line tools is inconsistent, and should
> be avoided.

I'm a big fan of consistency. It's good for users. It's good for
developers. It's great for parents. And drummers. I too, oppose this
change, for the reasons Hyrum has so pleasantly stated.

--
C. Michael Pilato <cmpilato@...>
CollabNet <> www.collab.net <> Distributed Development On Demand

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427081

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

signature.asc (204 bytes) Download Attachment

Re: [PATCH][RFC] allow local file:// URLs for svnadmin

2009-12-04T07:15:23Z

On Fri, 2009-12-04 at 16:05 +0100, Vincent Legoll wrote:

> On Fri, Dec 4, 2009 at 3:50 PM, Julian Foad <julianfoad@...> wrote:
> > Vincent Legoll wrote:
> >> I think there's nothing preventing svnadmin to accept local
> >> file:// URLs as repository location parameter. So why not ?
> >
> > Let me ask a different question: Why? (We don't add features just
> > because we can, we add them because they are useful enough to
> > be worth the maintenance.)
>
> I understand the maintenance burden, and that was the point I wanted
> to raise with that question about usefulness.
>
> > I can think of a reason: it could be handy to copying URLs between
> > "svn" and "svnlook" and "svnadmin" commands.
>
> That's what make me try to do the patch, I didn't cut'n'paste from
> another svn* command but from a tailor (SCM migration tool) config
> file, but that's the idea behind the patch yes...
>
> > Is that your reason? Is there any stronger reason?
>
> Yes, user-least-surprise or you-try-something-and-it-just-work,
> when I saw the error message about URL not being accepted,
> I told myself: "WTF, this is a damn local file:// URL"

OK. It sounds like a good idea to me.

> > Would you add it to svnlook as well?
>
> If the idea is acceptable and the work I'll put into is not lost, yes
> I'll do it.

Great. I would keep an eye out for the next day or two in case anyone
disagrees.

> > If you want to do this, remember that converting a URL to a local path
> > is not as simple as stripping off a prefix: there are at least two
> > different prefixes (file://localhost as well), and you have to un-escape
> > the URL escaping.
>
> Yes, I think the final patch will be somewhat bigger, I didn't actually
> look, but will, maybe URL handling code that could be borrowed is already
> there...

See svn_path_uri_decode().

> Thanks for the quick answer

A pleasure.

- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427074

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

Re: [PATCH][RFC] allow local file:// URLs for svnadmin

2009-12-04T07:14:04Z

On Dec 4, 2009, at 6:50 AM, Julian Foad wrote:

> Vincent Legoll wrote:
>> Hello,
>>
>> would such kind of patch be acceptable or is this useless ?
>>
>> I think there's nothing preventing svnadmin to accept local
>> file:// URLs as repository location parameter. So why not ?
>
> Let me ask a different question: Why? (We don't add features just
> because we can, we add them because they are useful enough to be worth
> the maintenance.)
>
> I can think of a reason: it could be handy to copying URLs between "svn"
> and "svnlook" and "svnadmin" commands. Is that your reason? Is there any
> stronger reason? Would you add it to svnlook as well?
>
> If you want to do this, remember that converting a URL to a local path
> is not as simple as stripping off a prefix: there are at least two
> different prefixes (file://localhost as well), and you have to un-escape
> the URL escaping.

My initial reaction is about consistency. I can't think of any place we accept URLs as parameters to svnadmin, and I'm really hesitant to start doing so. In the command-line client, when we say "URL" we mean *any* well-formed URL, not just those with a specific access method. Changing that meaning on any of the command-line tools is inconsistent, and should be avoided.

-Hyrum

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427073

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

Re: [PATCH][RFC] allow local file:// URLs for svnadmin

2009-12-04T07:05:45Z

On Fri, Dec 4, 2009 at 3:50 PM, Julian Foad <julianfoad@...> wrote:
> Vincent Legoll wrote:
>> I think there's nothing preventing svnadmin to accept local
>> file:// URLs as repository location parameter. So why not ?
>
> Let me ask a different question: Why? (We don't add features just
> because we can, we add them because they are useful enough to
> be worth the maintenance.)

I understand the maintenance burden, and that was the point I wanted
to raise with that question about usefulness.

> I can think of a reason: it could be handy to copying URLs between
> "svn" and "svnlook" and "svnadmin" commands.

That's what make me try to do the patch, I didn't cut'n'paste from
another svn* command but from a tailor (SCM migration tool) config
file, but that's the idea behind the patch yes...

> Is that your reason? Is there any stronger reason?

Yes, user-least-surprise or you-try-something-and-it-just-work,
when I saw the error message about URL not being accepted,
I told myself: "WTF, this is a damn local file:// URL"

> Would you add it to svnlook as well?

If the idea is acceptable and the work I'll put into is not lost, yes
I'll do it.

> If you want to do this, remember that converting a URL to a local path
> is not as simple as stripping off a prefix: there are at least two
> different prefixes (file://localhost as well), and you have to un-escape
> the URL escaping.

Yes, I think the final patch will be somewhat bigger, I didn't actually
look, but will, maybe URL handling code that could be borrowed is already
there...

Thanks for the quick answer

--
Vincent Legoll

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427067

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

[PATCH] Clarify the description of FSFS node-revision ids

2009-12-04T06:57:58Z

Can anyone with a clue about FSFS check this patch:

[[[
* subversion/libsvn_fs_fs/structure
Expand and clarify the description of FSFS node-revision ids.
Fix a typo.
]]]

- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427059

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.
* subversion/libsvn_fs_fs/structure
Expand and clarify the description of FSFS node-revision ids.
Fix a typo.
--This line, and those below, will be ignored--

Note: in the diff below, indentation changes are not shown in full.

Index: subversion/libsvn_fs_fs/structure
===================================================================
--- subversion/libsvn_fs_fs/structure (revision 887172)
+++ subversion/libsvn_fs_fs/structure (working copy)
@@ -224,16 +224,32 @@ character.
Node-revision IDs
-----------------

+A node-rev ID consists of the following three fields:
+
+ node_revision_id ::= node_id '.' copy_id '.' txn_id
+
+At this level, the form of the ID is the same as for BDB - see the
+section called "ID's" in <../libsvn_fs_base/notes/structure>.
+
In order to support efficient lookup of node-revisions by their IDs
and to simplify the allocation of fresh node-IDs during a transaction,
-we treat the fields of a node-ID in new and interesting ways.
+we treat the fields of a node-rev ID in new and interesting ways.

-Within a revision file, node-revs have a txn-id field of the form
-"r<rev>/<offset>", to support easy lookup. New node-revision IDs
-assigned within a transaction have the txn-id field of "t<txnid>".
+Within a new transaction:
+
+ New node-revision IDs assigned within a transaction have a txn-id
+ field of the form "t<txnid>".

When a new node-id or copy-id is assigned in a transaction, the ID
used is a "_" followed by a base36 number unique to the transaction.
+
+Within a revision:
+
+ Within a revision file, node-revs have a txn-id field of the form
+ "r<rev>/<offset>", to support easy lookup. The <offset> is the (ASCII
+ decimal) number of bytes from the start of the revision file to the
+ start of the node-rev.
+
During the final phase of a commit, node-revision IDs are rewritten
to have repository-wide unique node-ID and copy-ID fields, and to have
"r<rev>/<offset>" txn-id fields.
@@ -252,7 +268,7 @@ added to the transaction-specific base36
this just prevents I/O-less node-origin-rev lookup for those nodes.)

The temporary assignment of node-ID and copy-ID fields has
-implications for svn_fs_compare_ids and svn_fs_check_related. The IDs
+implications for svn_fs_compare_ids and svn_fs_check_related. The ID
_1.0.t1 is not related to the ID _1.0.t2 even though they have the
same node-ID, because temporary node-IDs are restricted in scope to
the transactions they belong to.

Re: valgrind UMRs in "svn merge --record-only"

2009-12-04T06:53:10Z

On Wed, Dec 2, 2009 at 10:41 AM, Philip Martin
<philip.martin@...> wrote:

> Paul Burba <ptburba@...> writes:
>
>>> How is the user supposed to have any
>>> confidence that they have run the command correctly,
>>
>> How would a notification really help them know they ran the command
>> *correctly*? Like any merge, choose the wrong source, the wrong
>> target, the wrong revision, you get the wrong result. I don't see how
>> improved notifications avoid the need to check svn status, diff,
>> and/or propget svn:mergeinfo after the merge, to see if the result is
>> what was expected. Admittedly --record-only merges are particularly
>> problematic because there are no text or tree conflicts to alert us
>> that we might have screwed up, but I still don't see how notifications
>> help users much in confirming correctness.
>
> I could ask why normal merge produces notification, after all the user
> has to check status and diff to ensure that the merge got applied
> correctly. Does that mean the normal merge notification is of no use?

Point taken.

> The obvious case where record-only notifications help is when the
> merge doesn't change anything, because I got the wrong source URL or
> revision. If I'm expecting to see a change and I get no notification
> then I know I made a mistake.

Ditto.

>> Possibly I am thinking of too simplistic a notification. I assume the
>> notification would be something like this in the simple case (i.e. no
>> pre-existing subtree mergeinfo, no incoming mergeinfo diffs):
>>
>> svn merge ^^/trunk branches\b1.0 -c357 --record-only
>> --- Recording mergeinfo for r357 into 'branches\b1.0':
>> U branches\b1.0
>
> I was thinking just the U line.

I think a "record only" header is necessary. Now that --record-only
merges may apply svn:mergeinfo diffs, we might also see traditional
merge notification headers. Without a special header it looks like
all notifications are related to the diff, which IMO is quite
confusing.

For example, we have a WC merge target with no pre-existing mergeinfo:

>svn pg svn:mergeinfo -vR A2\D\G

We want to merge a rev from some other branch that includes
svn:mergeinfo property changes:

>svn diff ^^/A_COPY/D/G -c11
Index: rho
===================================================================
--- rho (revision 10)
+++ rho (revision 11)
@@ -1 +1 @@
-This is the file 'rho'.
+New content
\ No newline at end of file

Property changes on: rho
___________________________________________________________________
Added: svn:mergeinfo
Merged /A/D/G/rho:r4

Currently in trunk(@887205) the merge produces a notification only for
the mergeinfo change:

>svn merge --record-only -c11 ^^/A_COPY/D/G A2\D\G
--- Merging r11 into 'A2\D\G':
U A2\D\G\rho

But of course the --record-only logic recorded mergeinfo *describing*
the merge on the target too:

>svn st
M A2\D\G
M A2\D\G\rho

>svn pg svn:mergeinfo -vR A2\D\G
Properties on 'A2\D\G\rho':
svn:mergeinfo
/A/D/G/rho:4
/A_COPY/D/G/rho:11
Properties on 'A2\D\G':
svn:mergeinfo
/A_COPY/D/G:11

If we add notifications for mergeinfo changes describing the merge it
would look something like this...

>svn merge --record-only -c11 ^^/A_COPY/D/G A2\D\G
--- Merging r11 into 'A2\D\G':
U A2\D\G\rho
U A2\D\G

...Which makes it appear that the change to A2/D/G was part of the
diff. I think it is a lot clearer if the mergeinfo changes made to
describe the merge have their own special header:

>svn merge --record-only -c11 ^^/A_COPY/D/G A2\D\G
--- Merging r11 into 'A2\D\G':
U A2\D\G\rho
--- Recording mergeinfo for r11 into 'A2\D\G':
U A2\D\G

This isn't a big deal in simple examples, but if there are mergeinfo
diffs applied to many subtrees *and* many subtrees with pre-existing
mergeinfo, then things get quite ugly.

Paul

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427057

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

Re: [PATCH][RFC] allow local file:// URLs for svnadmin

2009-12-04T06:50:19Z

Vincent Legoll wrote:
> Hello,
>
> would such kind of patch be acceptable or is this useless ?
>
> I think there's nothing preventing svnadmin to accept local
> file:// URLs as repository location parameter. So why not ?

Let me ask a different question: Why? (We don't add features just
because we can, we add them because they are useful enough to be worth
the maintenance.)

I can think of a reason: it could be handy to copying URLs between "svn"
and "svnlook" and "svnadmin" commands. Is that your reason? Is there any
stronger reason? Would you add it to svnlook as well?

If you want to do this, remember that converting a URL to a local path
is not as simple as stripping off a prefix: there are at least two
different prefixes (file://localhost as well), and you have to un-escape
the URL escaping.

- Julian

> The attached patch, is probably wrong (you tell me) as my
> C is a bit rusty, but should show the intended change...
>
> Comments, reviews, flames, etc... All gladly accepted.
>
> If this is deemed useful, I'll especially would like directions
> on how to improve the patch to make it suitable for a real
> submission...
>
> --
> Vincent Legoll
>
> ###################### Inline ########################
>
> --- a/main.c
> +++ b/main.c
> @@ -133,6 +133,15 @@ parse_local_repos_path(apr_getopt_t *os,
> }
> else if (svn_path_is_url(*repos_path))
> {
> + #define URL_LOCAL_FILE_PREFIX "file://"
> + if (strncmp(*repos_path, URL_LOCAL_FILE_PREFIX,
> + strlen(URL_LOCAL_FILE_PREFIX)))
> + {
> + *repos_path = svn_dirent_internal_style(*repos_path +
> + strlen(URL_LOCAL_FILE_PREFIX), pool);
> + return SVN_NO_ERROR;
> + }
> +
> return svn_error_createf(SVN_ERR_CL_ARG_PARSING_ERROR, NULL,
> _("'%s' is an URL when it should be a path"),
> *repos_path);

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427054

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

[PATCH][RFC] allow local file:// URLs for svnadmin

2009-12-04T06:35:02Z

Hello,

would such kind of patch be acceptable or is this useless ?

I think there's nothing preventing svnadmin to accept local
file:// URLs as repository location parameter. So why not ?

The attached patch, is probably wrong (you tell me) as my
C is a bit rusty, but should show the intended change...

Comments, reviews, flames, etc... All gladly accepted.

If this is deemed useful, I'll especially would like directions
on how to improve the patch to make it suitable for a real
submission...

--
Vincent Legoll

###################### Inline ########################

--- a/main.c
+++ b/main.c
@@ -133,6 +133,15 @@ parse_local_repos_path(apr_getopt_t *os,
}
else if (svn_path_is_url(*repos_path))
{
+ #define URL_LOCAL_FILE_PREFIX "file://"
+ if (strncmp(*repos_path, URL_LOCAL_FILE_PREFIX,
+ strlen(URL_LOCAL_FILE_PREFIX)))
+ {
+ *repos_path = svn_dirent_internal_style(*repos_path +
+ strlen(URL_LOCAL_FILE_PREFIX), pool);
+ return SVN_NO_ERROR;
+ }
+
return svn_error_createf(SVN_ERR_CL_ARG_PARSING_ERROR, NULL,
_("'%s' is an URL when it should be a path"),
*repos_path);

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2427043

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

t (922 bytes) Download Attachment

[ANN] SVNKit 1.3.2 (GA) is available.

2009-12-03T16:49:45Z

Hello All,

We are glad to announce that SVNKit 1.3.2 has been published and
available for download at http://svnkit.com/ web site.

SVNKit is a pure Java Subversion library. SVNKit provides Java APIs to
access and manipulate Subversion working copies and Subversion
repositories. You may find more information, documentation and source
code examples at http://svnkit.com/

SVNKit 1.3.2 supports virtually all Subversion 1.6.6 features. Also,
we make sure that all native Subversion tests pass when ran against
SVNKit and that is more than 2500 tests in total.

SVNKit uses SQLJet - our new project that we use to work with SQLite
databases.
To learn more on SQLJet, please visit its home page at http://sqljet.com/.

New in version 1.3.2 (since version 1.3.1):

+ Changes made in Subversion since version 1.6.5 implemented,
all Subversion 1.6.6 features are supported.

* Negotiate authorization mechanism was not used when multiple
authorization
schemes were offered to client by server.
* SQLJet library upgraded to version 1.0.1.
* JNA library upgraded to version 3.2.3.

+ Bugfixes and performance improvements.

You're welcome to download and use SVNKit 1.3.2. We'll be glad to
provide help and support for the new version in our mailing list or by
email (support@...).

Useful links (more at http://svnkit.com/):

* SVNKit Continuous Integration Server: https://teamcity.svnkit.com/
* SVNKit Source Code Repository: http://svn.svnkit.com/repos/svnkit/
* SVNKit Update Site (for Eclipse): http://eclipse.svnkit.com/1.3.x/
* SVNKit Mailing List: http://www.nabble.com/SVNKit---Users-f18684.html
* SVNKit/SQLJet Maven Repository: http://maven.svnkit.com/maven2/
* Central Maven Repository: http://repo2.maven.org/maven2/

--------------------------------------------------------------------------
Maven dependency details.

SVNKit:

With JNA version 3.2.3 dependency which is not in the Maven central yet:

Group ID: org.tmatesoft.svnkit
Artifact ID: svnkit
Version: 1.3.2

With JNA version 3.2.2 dependency:

Group ID: org.tmatesoft.svnkit
Artifact ID: svnkit
Version: 1.3.2-1

SQLJet:

Group ID: org.tmatesoft.sqljet
Artifact ID: sqljet
Version: 1.0.1
--------------------------------------------------------------------------

There are also JNA and Trilead maven artifacts in our repository.

Note for Eclipse (Subclipse) users:

Those of you who use SVNKit 1.3.1 as an Eclipse plug-in (e.g. Subclipse
1.6.x users) are strongly advised to update SVNKit with the help of
SVNKit update site: http://eclipse.svnkit.com/1.3.x/

SVNKit consists of two plug-ins - Core SVNKit and JNA Library, we
recommend to install both plug-ins. SVNKit plug-ins are OSGI-compatible.

The best available version of SVNKit is 1.3.2.6267 (that is 1.3.2 GA).

In case you experience problems with updating existing SVNKit version
from within Eclipse, then deleting and creating update site again may
help to resolve that problem (see Help | Software Updates | Available
Updates | Manage Sites).

With best regards,
SVNKit Development Team.

----
Alexander Sinyushkin,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
http://sqljet.com/ - Java SQLite Library!

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2426869

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

Re: [PATCH] gpg-agent support

2009-12-03T16:45:33Z

Hi Dan,

Just thought I would chase up you patch proposal and see if you're still working on it, or not?
Also - While I might be stating the obvious, please do not hesitate to ask for any help you might need.

Gavin.

On 26/11/2009, at 23:55 , Philip Martin wrote:

> Dan Engel <dengel@...> writes:
>
>> Thanks for the comments, Philip.
>>
>> So, what's the protocol? Do I fix things up per suggestions, re-diff
>> against the (by then) latest trunk, and re-submit?
>
> Yes, please.
>
> --
> Philip
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2424590
>
> Please start new threads on the <dev@...> mailing list.
> To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2426868

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

Re: mod_dav_svn and multiple apache processes

2009-12-03T13:29:38Z

Yes, mod_dav_svn may open and close BDB databases multiple times over the
course of a commit.

HTTP/WebDAV is a stateless protocol. "Stateless" means (in this case) that
a commit -- which consists of many client->server requests (OPTIONS,
MKACTIVITY, PROPPATCH, CHECKOUT, PUT, COPY, MERGE, ...) and their responses
-- happens in phases, each phase carrying enough information to remind the
server of what the previous phases accomplished (and/or how to figure that
out for itself). Because of this, you could theoretically shutdown and
restart your Apache server between each and every request of a single
Subversion commit operation, and things would work just fine.

I think you are confusing a number of concepts: the HIGH-LEVEL SVN COMMIT
OPERATION, which happens using one or more CONNECTIONS to the Apache server,
through each of which one or more REQUESTS is sent and responses received,
all of which work to make piecemeal modifications to a single SUBVERSION
REPOSITORY COMMIT TRANSACTION. Until to understand those elements, not much
more of what I say is going to make very much sense.

Viacheslav Zholudev wrote:

> Hi Michael,
>
> I had a closer look and I figured out the following. SVN may open and
> close BDB databases MORE than once during ONE svn commit (i.e. during 1
> svn transaction), and create svn_fs_t objects multiple times. Is it
> normal behavior? Could it be because Apache decides to clean caches, and
> then recreates an svn_fs_t object since the previous one was cleaned up
> and closed? As far as understood from your former emails, only one cached
> svn_fs_t object should be used by mod_dav_svn PER 1 svn transaction (e.g.
> commit). But I'm seeing the opposite situation...
>
> Could you please clarify? Thanks a lot for your time.
>
> Best, Vyacheslav
>
>
> On Dec 2, 2009, at 4:01 PM, C. Michael Pilato wrote:
>
>> Viacheslav Zholudev wrote:
>>> thanks for the answer. It sufficiently clarifies things for me.
>>> However, I have one more question: Let's assume that SVN client
>>> commits two big files in the same SVN transaction. Could it happen
>>> that mod_dav_svn writes pieces of those two big files to the
>>> "strings" simultaneously? I.e. part1_file1, part1_file2, part2_file1,
>>> part2_file2 or in some other mixed order?
>> Today's Subversion clients won't do that. They serialize the
>> transmission of file contents towards the server. But putting that
>> aside, the BDB code keeps one file's contents in the 'strings' table
>> separate from another's by assigning the contents to different database
>> keys. So while a single client may not write to two different files in
>> the same transaction, it's certainly the case that multiple clients
>> could be tossing file contents for multiple files into the 'strings'
>> table simultaneous. The code does the right thing though -- it's not
>> like you're going to get corruption or anything that appears like a
>> file has interleaved content from various sources.
>>
>> What's the source of your interest? Are you seeing a problem?
>>
>> -- C. Michael Pilato <cmpilato@...> CollabNet <>
>> www.collab.net <> Distributed Development On Demand
>>
>
> Best, Vyacheslav
>
>
>

--
C. Michael Pilato <cmpilato@...>
CollabNet <> www.collab.net <> Distributed Development On Demand

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2426833

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

signature.asc (204 bytes) Download Attachment

Re: mod_dav_svn and multiple apache processes

2009-12-03T12:36:21Z

Hi Michael,

I had a closer look and I figured out the following. SVN may open and close BDB databases MORE than once during ONE svn commit (i.e. during 1 svn transaction), and create svn_fs_t objects multiple times. Is it normal behavior? Could it be because Apache decides to clean caches, and then recreates an svn_fs_t object since the previous one was cleaned up and closed? As far as understood from your former emails, only one cached svn_fs_t object should be used by mod_dav_svn PER 1 svn transaction (e.g. commit). But I'm seeing the opposite situation...

Could you please clarify? Thanks a lot for your time.

Best,
Vyacheslav

On Dec 2, 2009, at 4:01 PM, C. Michael Pilato wrote:

> Viacheslav Zholudev wrote:
>> thanks for the answer. It sufficiently clarifies things for me. However,
>> I have one more question: Let's assume that SVN client commits two big
>> files in the same SVN transaction. Could it happen that mod_dav_svn
>> writes pieces of those two big files to the "strings" simultaneously?
>> I.e. part1_file1, part1_file2, part2_file1, part2_file2 or in some other
>> mixed order?
>
> Today's Subversion clients won't do that. They serialize the transmission
> of file contents towards the server. But putting that aside, the BDB code
> keeps one file's contents in the 'strings' table separate from another's by
> assigning the contents to different database keys. So while a single client
> may not write to two different files in the same transaction, it's certainly
> the case that multiple clients could be tossing file contents for multiple
> files into the 'strings' table simultaneous. The code does the right thing
> though -- it's not like you're going to get corruption or anything that
> appears like a file has interleaved content from various sources.
>
> What's the source of your interest? Are you seeing a problem?
>
> --
> C. Michael Pilato <cmpilato@...>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>

Best,
Vyacheslav

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2426822

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

Re: [PATCH] Extend 'svn diff URL URL' to 'svn diff URL URL [WC]'

2009-12-03T07:06:50Z

C. Michael Pilato wrote:
> Is this the same meaning as:
>
> svn diff --old=^/repo/branches/foo --new=^/repo/branches/bar path/to/wc
>
> ?

Never mind. Replied before fully processing the mail thread.

--
C. Michael Pilato <cmpilato@...>
CollabNet <> www.collab.net <> Distributed Development On Demand

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2426717

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

signature.asc (204 bytes) Download Attachment

Re: [PATCH] Extend 'svn diff URL URL' to 'svn diff URL URL [WC]'

2009-12-03T07:01:45Z

Philip Martin wrote:

> It's possible to compare branches in the repository using
>
> $ svn diff ^/repo/branches/foo ^/repo/branches/bar
>
> but that only works if the current directory is a working copy because
> libsvn_client/cmdline.c:svn_client_args_to_target_array converts
> relative URLs to full URLs using the hardcoded path "". Since I
> regularly have my current working directory outside a working copy
> this is inconvenient.
>
> I'd like to be able to do
>
> $ svn diff ^/repo/branches/foo ^/repo/branches/bar path/to/wc
>
> and it turns out to be quite simple from a code point of view. It is,
> of course, an extension to our rather complex diff UI. What do people
> think?

Is this the same meaning as:

svn diff --old=^/repo/branches/foo --new=^/repo/branches/bar path/to/wc

?

--
C. Michael Pilato <cmpilato@...>
CollabNet <> www.collab.net <> Distributed Development On Demand

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2426716

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

signature.asc (204 bytes) Download Attachment

Re: Subversion: integration of certificate based login

2009-12-03T06:39:54Z

Your question is about using Subversion, and as such, it should be sent to the users list:
users@....

Thanks!

-Hyrum

On Dec 3, 2009, at 1:26 AM, Markus Oberlassnig wrote:

> Hello,
>
> we need to integrate certificate based login to subversion, subclipse and tortoise.
> Is it possible to configure svn, so that a user (client) can be authorized by a certificate (X509 and / or PKCS11) without additional login.
> When yes, how can this be done?
> When no, can you give me hints, how to develop this feature or who can develop this feature?
>
> We also need to read the client certificate from a smart card. Is it correct that we can use opensc for this feature?
>
> Please can you help me.
>
> Nice regard ,
> Markus Oberlassnig
>
>
> DI Markus Oberlassnig
> Senior Consultant
> -------------------------------
> ilogs information logistics GmbH
> Krone Platz 1
> 9020 Klagenfurt am Wörthersee
> Austria
> www.ilogs.com
>
> T: +43 463 504 197 41
> F: +43 463 504 197 55
> M: +43 676 844 442 350
>
>
>
> __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version 4656 (20091202) __________
>
> E-Mail wurde geprüft mit ESET NOD32 Antivirus.
>
> http://www.eset.com

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2426714

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

Re: [PATCH] Extend 'svn diff URL URL' to 'svn diff URL URL [WC]'

2009-12-03T06:00:33Z

Julian Foad <julianfoad@...> writes:

> Philip Martin wrote:
>> Julian Foad <julian.foad@...> writes:
>>
>> >> > > $ svn diff ^/repo/branches/foo ^/repo/branches/bar --repos=[URL|WC]
>> >> >
>> >> > But that's much harder to type.
>> >
>> > Yup. :-) But not if you configure it somewhere so you don't have to type
>> > it.
>>
>> So your solution is I should define an alias that allows me to type
>> 'svndiff ^/foo ^/bar wc' to run 'svn diff ^/foo ^/bar --repos=wc'.
>
> I didn't say that.

Then I'm not sure what you did mean.

>> I'd prefer to fix the client.
>>
>> >> Also the new syntax is consistent
>> >> > with most of the other commands that use '.' as a default, if one
>> >> > doesn't want to use '.' one specifies the path explicitly:
>> >
>> > No, hardly any commands take a WC argument which they only use to
>> > identify the repository. They nearly all focus their behaviour onto the
>> > particular path you specify.
>>
>> Off the top of my head:
>>
>> $ svn log -rNNN
>> $ svn list ^/branches
>> $ svn diff -cNNN
>>
>> all will fail if wc is not a working copy and all will succeed if I
>> add a wc path.
>
> Sure, but they will produce output that relates to the WC path you
> specify, not just use it to find a repository and ignore it otherwise.

Perhaps. However

$ svn list ^/subversion/branches ../src/COMMITTERS

appears to use it just find a repository, and

$ svn merge ^/foo ^/bar wc

behaves in almost exactly the way I would like diff to behave. I
agree it does use the wc path beyond merely constructing URLs, but the
way it constructs URLs is the way I would like diff to behave.

>> Comparing two branches in a repository is not an obscure operation.
>> We should make it easy to invoke.
>
> Sure. I agree.
>
> Can you come on IRC #svn-dev where we can discuss more easily? (Actually
> I must go get some lunch and put dinner in the oven now, but in an hour
> or so?)

OK.

--
Philip

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2426707

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

Re: [PATCH] Extend 'svn diff URL URL' to 'svn diff URL URL [WC]'

2009-12-03T05:37:10Z

Philip Martin wrote:

> Julian Foad <julian.foad@...> writes:
>
> >> > > $ svn diff ^/repo/branches/foo ^/repo/branches/bar --repos=[URL|WC]
> >> >
> >> > But that's much harder to type.
> >
> > Yup. :-) But not if you configure it somewhere so you don't have to type
> > it.
>
> So your solution is I should define an alias that allows me to type
> 'svndiff ^/foo ^/bar wc' to run 'svn diff ^/foo ^/bar --repos=wc'.

I didn't say that.

> I'd prefer to fix the client.
>
> >> Also the new syntax is consistent
> >> > with most of the other commands that use '.' as a default, if one
> >> > doesn't want to use '.' one specifies the path explicitly:
> >
> > No, hardly any commands take a WC argument which they only use to
> > identify the repository. They nearly all focus their behaviour onto the
> > particular path you specify.
>
> Off the top of my head:
>
> $ svn log -rNNN
> $ svn list ^/branches
> $ svn diff -cNNN
>
> all will fail if wc is not a working copy and all will succeed if I
> add a wc path.

Sure, but they will produce output that relates to the WC path you
specify, not just use it to find a repository and ignore it otherwise.

> Comparing two branches in a repository is not an obscure operation.
> We should make it easy to invoke.

Sure. I agree.

Can you come on IRC #svn-dev where we can discuss more easily? (Actually
I must go get some lunch and put dinner in the oven now, but in an hour
or so?)

- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2426702

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.

RE: svnsync large files

2009-12-03T05:32:58Z

On Wed, 2009-12-02, Bitts, Daniel wrote:

Ah, so now you show us the error message :-)

> The slave was https://slave.suffolk.inside/slavesvn, and svnsync was
> executed on the master server.
>
> It's looking more like an Apache issue than an SVN issue, but still is
> puzzling because users are regularly committing large files into the
> master over the WAN link from the slave site.

Yes. Perhaps you should be looking for timeouts or data transfer limits
in the Apache config. (I know very little about Apache config.)

Is your "svnsync" process using the Neon or the Serf library to make its
HTTP connections, do you know? This might make a difference. We can find
out from the output of "svnsync --version" plus any "http-library"
option in the "~/.subversion/config" file of the home directory of the
user account under which "svnsync" runs.

Can you try using the other one (Neon or Serf), if "svnsync --version"
indicates it supports both?

- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2426700

Please start new threads on the <dev@...> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe@...>.