Issue in commit: Can't open activity db: Unrecognized resolver error

[Daniel]

In a working repository, I started to having the following error message:

Commit
Commit failed (details follow):
Can't open activity db: Unrecognized resolver error

I checked that svn/repo/dav and it has 777 permissions, then I chown all the
repo with 777 but still have the same error

Any ideas?

Note: the environment is Solaris

Thanks,
Daniel

Re: Issue in commit: Can't open activity db: Unrecognized resolver error

[Daniel]

This is the apache log:

[error] [client 10.48.129.165] could not open dbm files.  [500, #5527096]
[error] [client 10.48.129.165] Can't open activity db: Unrecognized resolver
error  [500, #5527096]


On Sat, May 21, 2011 at 6:47 AM, Daniel Shahaf wrote:

> Try figuring out what the error number is.
>
> (the error text comes from apr_os_strerror(), see there for pointers on
> how to interpret the error number)
>
> Daniel wrote on Thu, May 19, 2011 at 18:12:10 -0300:
> > In a working repository, I started to having the following error message:
> >
> > Commit
> > Commit failed (details follow):
> > Can't open activity db: Unrecognized resolver error
> >
> > I checked that svn/repo/dav and it has 777 permissions, then I chown all
> the
> > repo with 777 but still have the same error
> >
> > Any ideas?
> >
> > Note: the environment is Solaris
> >
> > Thanks,
> > Daniel
>



-- 
_
*
 Daniel Oliva Bianco*
_

Re: [PATCH] Fix missing log-item close tag in on-the-wire XML

[Daniel Sahlberg]

Den mån 14 okt. 2024 kl 13:07 skrev Franz Sirl <
franz.sirl-ker...@lauterbach.com>:

> Hi,
>
> the attached patch fixes both issue 4856 and the (different) bug
> we were seeing in one of our own repositories.
> The problem boils down to the fact that with `svn log --xml --verbose`
> a log-item is opened every time the PATH_CHANGE_RECEIVER callback is
> used. But if the revision is later declared "unimportant", the
> corresponding log-item closure is never sent via the REVISION_RECEIVER
> callback.
>
> The patch fixes that by always using an intermediate callback routine
> and recording the call of inner() in a new flag in
> interesting_merge_baton_t. This flag is then used to decide if the
> REVISION_RECEIVER callback has to be called to close the log-item.
>
> With yet another flag in interesting_merge_baton_t record_inner_call()
> could be merged into interesting_merge() if you prefer that.
>

Thank you for the patch!

In the discussion about issue 4177, Daniel Shahaf mentioned that there was
an inconsistency about the number of times the receiver callback was
called, so it seems likely you have found that issue.

I'm going to test this further when time permits, hopefully this week.

Kind regards,
Daniel

Re: svn log gives E130003: Malformed XML via DAV

[Daniel Sahlberg]

On 2024/10/01 14:00:54 Franz Sirl wrote:
(snip)
> PS: While investigating that I found a small cosmetic bug in the 
> prototype (fortunately the code follows the definition) for do_logs() in 
> subversion/libsvn_repos/log.c:
> ```
> Index: subversion/libsvn_repos/log.c
> ===
> --- subversion/libsvn_repos/log.c   (revision 1921065)
> +++ subversion/libsvn_repos/log.c   (working copy)
> @@ -1719,8 +1719,8 @@
>   int limit,
>   svn_boolean_t strict_node_history,
>   svn_boolean_t include_merged_revisions,
> +    svn_boolean_t subtractive_merge,
>   svn_boolean_t handling_merged_revisions,
> -    svn_boolean_t subtractive_merge,
>   svn_boolean_t ignore_missing_locations,
>   const apr_array_header_t *revprops,
>   svn_boolean_t descending_order,
> ```

Thank you for the patch! I've comitted this in r1921423.

Kind regards,
Daniel

Re: How to delete fiiles on the server that were accidentally part of an import?

[Daniel Sahlberg]

Den tis 24 sep. 2024 kl 09:30 skrev Bo Berglund :

> Here the URL delete command is described as follows:
>
> $ svn delete -m "Deleting file 'yourfile'" \
>  file:///var/svn/repos/test/yourfile
>
> And that did not make sense to me because file: is NOT in my view an URL
> and
> also because they had entered a \ in the middle of the command, which also
> does
> not make sense to me...
>

file:// is a URL with the protocol "file:", just as http:// is a URL with
the protocol "http:". It is meant to be adjusted to whatever the URL is for
your repository. Remember that SVN can use at least five different
protocols so any one chosen would be "wrong" for a majority of the readers,
but other examples use both http://, svn:// and svn+ssh://.

The backslash character is a continuation character used in many Unix
shells to break up the command to several separate lines. It is used to
indicate "don't expect that you can press enter after the log message and
enter the URL on the next line". As someone pointed out ^ can be used in
Windows for the same function.

I'd be happy if we can improve the book to be more clear in this regard -
feel free to make a suggestion.

Kind regards,
Daniel

Re: How to file a feature request

[Daniel Shahaf]

James Fainer wrote on Wed, Oct 06, 2010 at 11:10:02 -0400:
> I would like to file a feature request but don't want to clutter the issue
> tracker inadvertently. What is the proper process? 
> 

To propose it on this list first.

>  
> 
> Jim Fainer
> 

Re: User authentication\authorization upper-lower case

[Daniel Shahaf]

No time to test, sorry, but agreed that usernames should be
case-sensitive.  Please file a bug if they aren't...

Bob Archer wrote on Fri, Oct 08, 2010 at 11:45:16 -0400:
> > On Fri, Oct 8, 2010 at 5:30 PM, Bob Archer 
> > wrote:
> > > >> Hi all. I have a problem with SVN. I have the (only) user
> > > >> 'test_user' (in the 'passwd' file) having 'rw' on the entire
> > > >> repository. Why am I able to get *authenticated* with the user
> > > >> 'TESTUSER' (but not *authorized* to commit)? Note that only
> > > >> authenticated user can access and read from my repository, so
> > > >> 'TESTUSER' should not be authenticated, as it happens for all
> > > the
> > > >> users not appearing in the passwd file, for example the
> > > 'BlaBlaBla'
> > > >> user.
> > > >> Thanks
> > > >You probably have anon access allowed. Are you using svn or
> > > apache/http? Perhaps showing us your config file would help. I
> > > >think authorization is only applied to authenticated users.
> > >
> > > >BOb
> > >
> > > anon-access = none
> > > password-db = passwd
> > > authz-db = authz
> > >
> > > I'm using svn (svnserve.exe). There is a mistake in the previous
> > > post: 'test_user' is without the '_' character. So the only user
> > in
> > > passwd is 'testuser'. Every user different from 'testuser' does
> > not
> > > get authentication, while 'TESTUSER' gets authentication, but
> > he's
> > > not authorized to commit. (while 'testuser' is). It seems that
> > > 'TESTUSER' and 'testuser' are the same from the authentication
> > > point of view, while they are different from the authorization
> > > point of view. Instead, I would expect for 'TESTUSER' to not be
> > > authenticated. Am I right or am I missing something? Thanks.
> > > On Fri, Oct 8, 2010 at 4:51 PM, Bob Archer 
> > > wrote:
> > You are possibly correct. I know that svn is case sensitive.
> > However, the authentication may not be. If you authenticate using
> > lower case can you do your commit?
> > 
> > BOb
> > 
> > Sure, 'testuser' can commit
> 
> So, it sounds like you have your answer. Authentication is not case 
> sensitive, yet authorization is. Seems like a bit of a bug to me. Perhaps a 
> svn dev will jump in here and let us know.
> 
> BOb
> 

Re: some confusion about subversion

[Daniel Shahaf]

肖晗 wrote on Sun, Oct 10, 2010 at 00:23:57 +0800:
> I am just new to subversion and encountered some confusion.
> I have set up a svn server on my ubuntu/linux.
> After creating an account called "test" under /var/svn(using svnadmin create
> /var/svn/test), I checked out the repository under "/home" directory.
> And all these went smoothly until when I tried to add some new files to the
> repository
> 
> When I added some files using "svn add *filename" *and checked the files in
> the repository(/var/svn/test), I didn't find any filename that matched the
> files I have just added.
> 
> So I wonder where my uploaded file goes.

It's there.  Somewhere under the db/ directory; where exactly (and how
exactly different revisions are stored) is opaque.

BTW, does anyone want to add this to the FAQ?  (just send a patch
against /site/publish/faq.html)

Re: Better way to get the full rule of the last commit?

[Daniel Becroft]

---
Daniel Becroft


On Mon, Oct 11, 2010 at 12:34 PM, Tech Geek  wrote:

> All my repositories live under /var/lib/svn/.
>
> Let's the output of the following command (on the SVN server):
> # svn changed /var/lib/svn/projectA/
> is
> A   PartA/tags/DEV-1.00_RC5/
>
> Now in my post-commit hook I need the following value in a variable (say
> EMAIL_URL):
> EMAIL_URL=/var/lib/svn/projectA/PartA/tags/DEV-1.00_RC5
>
> Right now the way I am getting this value in my post-commit hook is as
> follow:
>
> DIRCHANGE=`$SVNLOOK changed "$REPOS" | $GREP "^A\W.*" | cut -d' ' -f4`
> SRC_CO_PATH="$REPOS/$DIRCHANGE"
>
> Is there any command which will return the full path of the directory
> inside that repository under which the changes were made by the last commit?
>

Sure, you used it above. 'svnlook changed' will always return the path
(relative to the repository root) of the changed file.

However, what I think you are after, is the full URL (include repository
path) to that file. That is not possible for SVN to determine, as it does
not know *how* you are serving the repository (HTTP, HTTPS, svn+ssh, svn,
etc). $REPOS will give you the physical path to the repository, not
necessarily the publicly accessible path.

Cheers,
Daniel B.

Re: Bug report against SVN 1.6.13

[Daniel Shahaf]

Stefan Sperling wrote on Sat, Oct 16, 2010 at 15:40:46 +0200:
> On Fri, Oct 15, 2010 at 10:13:48PM +0200, Paul Maier wrote:
> > svn cp should always make the target file read-write in the
> > working copy.
> 
> No. A plain copy should carry file permissions of its source along,
> just like a normal (operating system) copy command does.
> 

+1

> Only in the special case where an uncommitted file has an svn:needs-lock
> property it should be read-write, because:
>  1) There is no way to get the lock to make the file read-write,
> so there's no point in having the file read-only
>  2) Noone else can see the file yet, anyway
> 

+1

> > Sounds like one command somewhere near the end of svn cp, isn't it?
> 
> I'd poke around in the code to see where the svn:needs-lock property
> is handled, and try to add a special case there for files which are
> locally added or copied.

I looked at svn_wc__maybe_set_read_only(), discovered it wasn't even
called during 'svn cp', and came up with the following patch:

[[[
Index: subversion/tests/cmdline/lock_tests.py
===
--- subversion/tests/cmdline/lock_tests.py  (revision 1023400)
+++ subversion/tests/cmdline/lock_tests.py  (working copy)
@@ -37,6 +37,23 @@ XFail = svntest.testcase.XFail
 Item = svntest.wc.StateItem
 
 ##
+# Helpers
+
+def check_writability(path, writable)
+  "Raise if PATH is not writable."
+  bits = stat.S_IWGRP | stat.S_IWOTH | stat.S_IWRITE
+  mode = os.stat(path)[0]
+  if bool(mode & bits) != writable:
+raise svntest.Failure("path '%s' is unexpectedly %s (mode %o)"
+  % (path, ["writable", "read-only"][writable], mode))
+
+def is_writable(path):
+  check_writability(path, True)
+
+def is_readonly(path):
+  check_writability(path, False)
+
+##
 # Tests
 
 #--
@@ -1573,6 +1590,39 @@ def replace_and_propset_locked_path(sbox):
  'commit', '-m', '', G_path)
 
 
+#--
+def cp_isnt_ro(sbox):
+  "uncommitted svn:needs-lock add/cp not read-only"
+
+  sbox.build()
+  wc_dir = sbox.wc_dir
+
+  mu_path = os.path.join(wc_dir, 'A', 'mu')
+  mu2_path = os.path.join(wc_dir, 'A', 'mu2')
+  kappa_path = os.path.join(wc_dir, 'kappa')
+  open(kappa_path, 'w').write("This is the file 'kappa'.\n")
+
+  # added file
+  sbox.simple_add(kappa_path)
+  svntest.actions.set_prop('svn:needs-lock', 'yes', kappa_path)
+  is_writable(kappa_path)
+  sbox.simple_commit(kappa_path)
+  is_readonly(kappa_path)
+
+  # versioned file
+  svntest.actions.set_prop('svn:needs-lock', 'yes', mu_path)
+  is_writable(mu_path)
+  sbox.simple_commit(mu_path)
+  is_readonly(mu_path)
+
+  # added-with-history file
+  svntest.actions.set_prop('svn:needs-lock', 'yes', mu_path)
+  svntest.main.run_svn(None, 'copy', mu_path, mu2_path)
+  is_writable(mu2_path)
+  sbox.simple_commit(mu2_path)
+  is_readonly(mu2_path)
+
+
 
 # Run the tests
 
@@ -1619,6 +1669,7 @@ test_list = [ None,
   verify_path_escaping,
   XFail(replace_and_propset_locked_path,
 svntest.main.is_ra_type_dav),
+  cp_isnt_ro,
 ]
 
 if __name__ == '__main__':
Index: subversion/libsvn_wc/copy.c
===
--- subversion/libsvn_wc/copy.c (revision 1023400)
+++ subversion/libsvn_wc/copy.c (working copy)
@@ -238,6 +238,17 @@ copy_versioned_file(svn_wc__db_t *db,
  tmpdir_abspath,
  TRUE, /* recursive */
  cancel_func, cancel_baton, scratch_pool));
+
+  /* Remove 'read-only' from the copied file. */
+{
+  const svn_string_t *needs_lock;
+  SVN_ERR(svn_wc__internal_propget(&needs_lock, db, src_abspath,
+       SVN_PROP_NEEDS_LOCK, scratch_pool,
+   scratch_pool));
+  if (needs_lock)
+svn_io_set_file_read_write(tmp_dst_abspath, FALSE, scratch_pool);
+}
+
   if (tmp_dst_abspath)
 {
   svn_skel_t *work_item;
]]]

Please review the regression test :-)

Thanks,

Daniel

Re: Bug report against SVN 1.6.13

[Daniel Shahaf]

Daniel Shahaf wrote on Sun, Oct 17, 2010 at 05:09:37 +0200:
> Index: subversion/libsvn_wc/copy.c
> ===
> --- subversion/libsvn_wc/copy.c   (revision 1023400)
> +++ subversion/libsvn_wc/copy.c   (working copy)
> @@ -238,6 +238,17 @@ copy_versioned_file(svn_wc__db_t *db,
>   tmpdir_abspath,
>   TRUE, /* recursive */
>   cancel_func, cancel_baton, scratch_pool));
> +
> +  /* Remove 'read-only' from the copied file. */
> +{
> +  const svn_string_t *needs_lock;
> +  SVN_ERR(svn_wc__internal_propget(&needs_lock, db, src_abspath,
> +   SVN_PROP_NEEDS_LOCK, scratch_pool,
> +   scratch_pool));
> +  if (needs_lock)
> +svn_io_set_file_read_write(tmp_dst_abspath, FALSE, scratch_pool);
> +}
> +
>if (tmp_dst_abspath)
>  {
>svn_skel_t *work_item;

Probably not a good idea to set_file_read_write(tmp_dst_abspath)
before the check that it's non-NULL.  I'll have to look into that.

Re: Bug report against SVN 1.6.13

[Daniel Shahaf]

Stefan Sperling wrote on Sun, Oct 17, 2010 at 14:43:57 +0200:
> Your patch seems to handle copies only. What about locally added files?

Does this part of the regression patch cover the scenario you have in mind?

Index: subversion/tests/cmdline/lock_tests.py
===
--- subversion/tests/cmdline/lock_tests.py  (revision 1023400)
+++ subversion/tests/cmdline/lock_tests.py  (working copy)
@@ -1573,6 +1590,39 @@ def replace_and_propset_locked_path(sbox):
+def cp_isnt_ro(sbox):
...
+  # added file
+  sbox.simple_add(kappa_path)
+  svntest.actions.set_prop('svn:needs-lock', 'yes', kappa_path)
+  is_writable(kappa_path)
+  sbox.simple_commit(kappa_path)
+  is_readonly(kappa_path)
...
@@ -1619,6 +1669,7 @@ test_list = [ None,
+  cp_isnt_ro,
   ]

Re: svn Farm

[Daniel Shahaf]

Nico Kadel-Garcia wrote on Sun, Oct 17, 2010 at 08:41:51 -0400:
> On Sun, Oct 17, 2010 at 3:52 AM, Alan Barrett  wrote:
> > On Sun, 17 Oct 2010, Nico Kadel-Garcia wrote:
> >> > What he really wants is an alternate-universe Subversion which never
> >> > had the plaintext password storage feature in the first place.
> >>
> >> I'd settle for being able to block that local use on the server side:
> >
> > OK, so you want a feature in which the client reports to the server
> > "here are some important aspects of my configuration", and the server
> > replies "I don't like  aspect of your configuration, so I refuse
> > to work with you".  I suggest that you write up a proposal for such a
> > feature, or begin a focused discussion about how such a feature could
> > work and could be useful.
> 
> I think the gpg-agent support will provide that by forcing people to a
> new authentication protocol. Won't that work?

http://article.gmane.org/gmane.comp.version-control.subversion.devel/121768

Re: Bug report against SVN 1.6.13

[Daniel Shahaf]

Stefan Sperling wrote on Sun, Oct 17, 2010 at 20:54:41 +0200:
> On Sun, Oct 17, 2010 at 04:30:41PM +0200, Daniel Shahaf wrote:
> > Stefan Sperling wrote on Sun, Oct 17, 2010 at 14:43:57 +0200:
> > > Your patch seems to handle copies only. What about locally added files?
> > 
> > Does this part of the regression patch cover the scenario you have in mind?
> 
> Yup. It does cover it.
> 
> Does this test already pass?
> 

Yes.  Committed r1023571.  Thanks.

Daniel

Re: Bug report against SVN 1.6.13

['Daniel Shahaf']

Paul Maier wrote on Sun, Oct 17, 2010 at 22:30:23 +0200:
> Hi Daniel,
> 
> thanks for having taken over this idea. 
> 

No problem.

> One question: 
> Does your solution code and testing code also cover the case when the copy 
> source is a URL?
> 
> svn cp svn://./a b
> should also leave file b as read-write, doesn't it?
> 

Should, but doesn't.

> Or if a whole directory is copied (from wc or from URL) and our file is 
> contained somewhere in the depth of that directory?
> 

Agreed, but haven't tested this.

> Thanks & regards,
>   Paul
>  

Well, you know the drill...  Would you like to patch that yourself?  If
not, could you file an issue (please include a link to this thread and
add 'danielsh' to the CC list), and I or someone else will get to it.

Re: Bug report against SVN 1.6.13

['Daniel Shahaf']

'Daniel Shahaf' wrote on Mon, Oct 18, 2010 at 00:24:13 +0200:
> Paul Maier wrote on Sun, Oct 17, 2010 at 22:30:23 +0200:
> > svn cp svn://./a b
> > should also leave file b as read-write, doesn't it?
> > 
> 
> Should, but doesn't.
> 

Fixed in r1023647, using the very same approach I originally
(unsuccessfully) tried for the previous patch :-)

Thanks for pointing out that the "source is URL to file" and "source is
URL to dir" cases should both be tested; in this case, they seem to
require separate fixes.

> > Or if a whole directory is copied (from wc or from URL) and our file
> > is contained somewhere in the depth of that directory?
> > 
> 
> Agreed, but haven't tested this.

This currently fails, presumably somewhere under repos_to_wc_copy_single()
-> svn_wc_add4().  I've pinged Julian on IRC, since he was refactoring the
latter function recently.  (also, at the moment that function isn't exactly
the clearest piece of code we have)

So there's still work to be done on this part.

Daniel

Re: Implementing lightweight client over http. Where to start?

[Daniel Shahaf]

To build an 'svn' client that speaks only ra_svn protocol, you'll need
to port only apr and apr-util.  No sqlite, no serf, no neon, no bdb.

You'll need to hack the build scripts to support such a client build.

(Oh, and the ra_svn protocol may be easier to reimplement than the
ra_dav protocol.)

Ryan Schmidt wrote on Mon, Oct 18, 2010 at 06:56:51 -0500:
> 
> On Oct 18, 2010, at 06:42, Andrew Roughan wrote:
> 
> > Porting the full svn client to my environment is not something I am willing 
> > to undertake myself.
> > So as an alternative I wanted to implement some Quick & Dirty interface 
> > over HTTP hopefully with a cleartext password.
> > Is there a document that describes the http interfaces to svn server for 
> > each function?
> 
> Subversion uses many other libraries to get its job done, including apr and 
> apr-util, expat, neon or serf, sqlite and others, and Subversion is itself 
> divided into several libraries that carry out the various tasks. I think if 
> the Subversion developers could have might Subversion lighter, they would 
> have, and I don't think you will be able to make any such "quick and dirty" 
> client without having to reimplement most of Subversion, which, as you may 
> know, represents ten years worth of work.
> 
> What is this mysterious environment you have where Subversion does not 
> already run?
> 
> To answer your question, the Subversion HTTP interface is WebDAV, so you can 
> read up on that.
> 

Re: Subversion equivalent to VSS diff for binary files

[Daniel Shahaf]

(didn't read it all very very carefully; was too long for that)

David Weintraub wrote on Mon, Oct 18, 2010 at 09:47:32 -0400:
> Text files are stored as diffs and removing a particular
> revision of a text file won't save a lot of room in the repository.
...
> However, binary files are a bit different. Changing one line in a file
> and then compiling it may cause a cascade of changes, so the resulting
> difference between the previous revision of the binary and current
> version of the binary are quite huge.
> 

Seems to me the solution is "Don't store your binaries in Subversion".

What does storing the binaries in Subversion gain? (as opposed to
storing all historical binaries in FTP somewhere)

> In fact, Subversion can, unlike many version control systems, actually
> distinguish between binary types [...].
> 

What are you referring to?

Re: svn Farm

[Daniel Shahaf]

Johan Corveleyn wrote on Tue, Oct 19, 2010 at 11:18:20 +0200:
> Maybe there is already some functionality present for protocol/feature
> negotiation, I don't know ...

All RA layers have a 'capability negotiation' support:
svn_ra_has_capability() allows the client to ask the server what it
supports.

In ra_svn the protocol supports bidirectional capabilities (i.e., it
allows the client to advertise capabilities to the server).  I don't
remember offhand if the ra_dav protocol supports that too.

Re: svn commit and branches

[Daniel Shahaf]

Brian Bird wrote on Tue, Oct 19, 2010 at 13:45:30 +0100:
> When committing to a branch in subversion (without the -m switch) svn
> pre-fills the editor with the filenames to be committed under a line
> "-This line, and those below, will be ignored-".
> 
> Is it possible for the current branch to be shown here as well?
> I often have to work on multiple branches and on occasion I have
> committed to the wrong branch and only realised later. I would like to
> be warned about the branch I'm on so I can switch to another one
> before committing if necessary. I know CVS used to show this
> information when committing so I'm hoping there's a simple option to
> enable this in svn?
> 

There isn't.  But you could teach your editor to show that information
if you need it (just run 'svn info').

> Thanks,
> 
> Brian

Re: Bug report against SVN 1.6.13

['Daniel Shahaf']

Paul Maier wrote on Wed, Oct 20, 2010 at 01:55:30 +0200:
> [Sorry, in my previous posting I forgot to mention the svn lock command. 
> Here the corrected version of my posting.]
> 
> Hi Daniel,
> 
> I just ran into something, that might already be fixed with your r1023571,
> but I think it is worth testing:
> 
> # 1. setup "file a" as in previous postings:
> echo a > a 
> svn add a 
> svn propset svn:needs-lock "*" a 
> svn ci -m "" 
> 
> # 2. local modification to file a:
> svn lock a
> echo blah >> a
> 
> # 3. rename file a:
> svn mv a b
> 
> # 4. want to continue to edit the file (has now name b):
> -> not possible, because on the "svn mv" the file turned read-only
> 
> 
> May I ask you to check if this is already covered by your r1023571?
> 

With head of trunk, 'b' isn't read-only:

0:% echo a > a
0:% $svn add -q a
0:% $svn ps svn:needs-lock yes -q a
0:% $svn ci -qmm
0:% 
0:% $svn lock -q a
Subcommand 'lock' doesn't accept option '-q [--quiet]'
Type 'svn help lock' for usage.
zsh: exit 1 $svn lock -q a
1:% $svn lock a   
'a' locked by user 'daniel'.
0:% echo blah >> a
0:% 
0:% $svn mv -q a b
0:% ls -l b
-rw-r--r-- 1 daniel daniel 7 2010-10-20 02:02 b
0:% 

Are you able to build svn yourself from source?

> Thanks & Greetings
>   Paul
> 

Re: 1.6.13: svn cleanup fails to cleanup

[Daniel Shahaf]

Paul Maier wrote on Wed, Oct 20, 2010 at 23:03:56 +0200:
> Hello!
> 
> I would be interested, if this problem is fixed in the 
> current 1.7 trunk.

It's not fixed, see transcript below.

Could you please file an issue in our tracker, linking to this thread?

(You'll have to create a tigris.org account for that.)

Thanks,

Daniel

> svn cleanup should be able to repair and unlock the WC.
> Unfortunately I am not able to build the trunk from source 
> myself.
> 
> Here is a reproduction script that produces a corrupt WC, and no 
> svn command can repair it, so the WC seems lost:
> 
> svnadmin create xx
> svn co "file:///C:/[...]/xx" yy
> cd yy
> echo a > a
> svn add a
> svn ci -m ""
> svn lock a
> svn mkdir 1
> mv a 1   # here "forgot" to type svn before the mv
> svn ci -m ""
> svn st -u
> svn cleanup 1
> svn cleanup .
> svn st -u
> 
> The error message advises to use svn cleanup, but svn cleanup 
> fails to unlock the WC. 
> (Even though it would be possible:
>   touch a;
>   svn cleanup .
> unlocks the WC.)

[[[
0:% cat foo.sh 
#!/bin/sh
$svnadmin create xx
$svn co file:///`pwd`/xx yy
cd yy
echo a > a
$svn add a
$svn ci -m ""
$svn lock a
$svn mkdir 1
mv a 1   # here "forgot" to type $svn before the mv
$svn ci -m ""
$svn st -u
$svn cleanup 1
$svn cleanup .
$svn st -u
touch a;
$svn cleanup .
0:% sh -x ./foo.sh
+ /home/daniel/src/svn/trunk/subversion/svnadmin/svnadmin create xx
++ pwd
+ /home/daniel/src/svn/trunk/subversion/svn/svn co file:tmp/svn/xx yy
Checked out revision 0.
+ cd yy
+ echo a
+ /home/daniel/src/svn/trunk/subversion/svn/svn add a
A a
+ /home/daniel/src/svn/trunk/subversion/svn/svn ci -m ''
Adding a
Transmitting file data .
Committed revision 1.
+ /home/daniel/src/svn/trunk/subversion/svn/svn lock a
'a' locked by user 'daniel'.
+ /home/daniel/src/svn/trunk/subversion/svn/svn mkdir 1
A 1
+ mv a 1
+ /home/daniel/src/svn/trunk/subversion/svn/svn ci -m ''
Adding 1

Committed revision 2.
subversion/svn/commit-cmd.c:156: (apr_err=20)
subversion/libsvn_client/commit.c:855: (apr_err=20)
svn: Commit succeeded, but other errors follow:
subversion/libsvn_client/commit.c:873: (apr_err=155009)
svn: Error bumping revisions post-commit (details follow):
subversion/libsvn_wc/adm_ops.c:510: (apr_err=155009)
subversion/libsvn_wc/workqueue.c:2282: (apr_err=155009)
subversion/libsvn_wc/workqueue.c:2217: (apr_err=155009)
subversion/libsvn_wc/workqueue.c:1311: (apr_err=155009)
svn: Error processing post-commit work for '/tmp/svn/yy/a'
subversion/libsvn_wc/workqueue.c:1134: (apr_err=2)
subversion/libsvn_wc/workqueue.c:880: (apr_err=2)
subversion/libsvn_subr/io.c:3630: (apr_err=2)
subversion/libsvn_subr/io.c:3561: (apr_err=2)
subversion/libsvn_subr/io.c:2764: (apr_err=2)
svn: Can't open file '/tmp/svn/yy/a': No such file or directory
+ /home/daniel/src/svn/trunk/subversion/svn/svn st -u
subversion/svn/status-cmd.c:326: (apr_err=155037)
subversion/svn/util.c:959: (apr_err=155037)
subversion/libsvn_client/status.c:300: (apr_err=155037)
subversion/libsvn_wc/node.c:193: (apr_err=155037)
subversion/libsvn_wc/wc_db.c:4350: (apr_err=155037)
subversion/libsvn_wc/wc_db_pdh.c:540: (apr_err=155037)
subversion/libsvn_wc/wc_db_pdh.c:268: (apr_err=155037)
subversion/libsvn_wc/wc_db_pdh.c:101: (apr_err=155037)
svn: Previous operation was interrupted; run 'svn cleanup'
+ /home/daniel/src/svn/trunk/subversion/svn/svn cleanup 1
subversion/svn/cleanup-cmd.c:82: (apr_err=155004)
subversion/libsvn_client/cleanup.c:64: (apr_err=155004)
subversion/libsvn_wc/cleanup.c:149: (apr_err=155004)
subversion/libsvn_wc/cleanup.c:92: (apr_err=155004)
subversion/libsvn_wc/wc_db.c:7409: (apr_err=155004)
subversion/libsvn_wc/wc_db.c:7409: (apr_err=155004)
svn: Working copy '/tmp/svn/yy/1' locked.
subversion/libsvn_wc/wc_db.c:7401: (apr_err=155004)
svn: '/tmp/svn/yy' is already locked.
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
+ /home/daniel/src/svn/trunk/subversion/svn/svn cleanup .
subversion/svn/cleanup-cmd.c:82: (apr_err=155009)
subversion/libsvn_client/cleanup.c:64: (apr_err=155009)
subversion/libsvn_wc/cleanup.c:149: (apr_err=155009)
subversion/libsvn_wc/cleanup.c:98: (apr_err=155009)
subversion/libsvn_wc/workqueue.c:2282: (apr_err=155009)
subversion/libsvn_wc/workqueue.c:2217: (apr_err=155009)
subversion/libsvn_wc/workqueue.c:1311: (apr_err=155009)
svn: Error processing post-commit work for '/tmp/svn/yy/a'
subversion/libsvn_wc/workqueue.c:1134: (apr_err=2)
subversion/libsvn_wc/workqueue.c:880: (apr_err=2)
subversion/libsvn_subr/io.c:3630: (apr_err=2)
subversion/libsvn_subr/io.c:3561: (apr_err=2)
subversion/libsvn_subr/io.c:2764: (apr_err=2)
svn: Can't open 

Re: Proper way to copy files between a branch and trunk

[Daniel Becroft]

On Fri, Oct 22, 2010 at 5:08 AM, Mark _  wrote:

>  Hi all,
>
> I have never understood the proper way to transfer files (or directories)
> between a branch and trunk and vice versa.
>
> Originally I thought the svn copy command was the best command to use, but
> then someone on this forum informed me that instead svn merge should be
> used, so that in the future updates can easily be transferered using svn
> merge again.
>
> The problem is...svn merge doesn't work :(
>
> Consider a very simple scenerio:
> I add a directory called myFeature to branchX.  I then want to copy this
> myFeature directory to trunk.  Using svn copy everything is fine.  But check
> what happens when I try to merge:
>
> $ svn merge http://svn/trunk/myfeat...@head
> http://svn/branches/branchX/myfeat...@1234 .
> svn: '/product/!svn/bc/389517/trunk/myFeature' path not found.
>

You've formatted your merge command incorrectly. Merges are done between
like levels on a tree. You shouldn't try to merge a subdirectory of a branch
with the root of trunk.

So, assuming branchX was created via a 'svn copy trunk branchX' command, and
the myFeature folder was added in r1234, then you would want to do the
following:

$ svn merge -c 1234 http://svn/branches/branchX .

If there were additional revisions that need to come across, then these
would need to be done as well.

Trying to think of the output as 'copy directory myFeature from this branch
to trunk' seems to be causing headaches. Instead, what you're after is 'take
this set of changes from this branch to trunk'.

Regards,
Daniel B.

Re: 1.6.13: svn cleanup fails to cleanup

[Daniel Shahaf]

Paul Maier wrote on Thu, Oct 21, 2010 at 21:28:43 +0200:
> > Could you please file an issue in our tracker, linking to this thread?
> 
> To be honest, I have no idea about the meaning of all the necessary
> parameters like priority and DEFECT or ENHANCEMENT and target milestone,
> that I really would appreciate if someone could file that issue for me.
> 

JFDI.  If you mess up the fields, someone can correct them after the
issue is filed.

I'd call this one a DEFECT.  There is no 'target milestone' field on the
'new issue' form (and appropriately so, since that field should be set
by the developers).

> Let's say, if nobody took over filing this issue till - say - weekend, 
> I will then try to do it.
> 
> Deal?
> 
> @Daniel: Thanks for having tested this!
> 

You're welcome, and thanks.

> Paul.
>  
> 
> > -Ursprüngliche Nachricht-
> > Von: Daniel Shahaf [mailto:d...@daniel.shahaf.name] 
> > Gesendet: Donnerstag, 21. Oktober 2010 15:49
> > An: Paul Maier
> > Cc: users@subversion.apache.org
> > Betreff: Re: 1.6.13: svn cleanup fails to cleanup
> > 
> > Paul Maier wrote on Wed, Oct 20, 2010 at 23:03:56 +0200:
> > > Hello!
> > > 
> > > I would be interested, if this problem is fixed in the 
> > > current 1.7 trunk.
> > 
> > It's not fixed, see transcript below.
> > 
> > Could you please file an issue in our tracker, linking to this thread?
> > 
> > (You'll have to create a tigris.org account for that.)
> > 
> > Thanks,
> > 
> > Daniel
> > 
> > > svn cleanup should be able to repair and unlock the WC.
> > > Unfortunately I am not able to build the trunk from source 
> > > myself.
> > > 
> > > Here is a reproduction script that produces a corrupt WC, and no 
> > > svn command can repair it, so the WC seems lost:
> > > 
> > > svnadmin create xx
> > > svn co "file:///C:/[...]/xx" yy
> > > cd yy
> > > echo a > a
> > > svn add a
> > > svn ci -m ""
> > > svn lock a
> > > svn mkdir 1
> > > mv a 1   # here "forgot" to type svn before the mv
> > > svn ci -m ""
> > > svn st -u
> > > svn cleanup 1
> > > svn cleanup .
> > > svn st -u
> > > 
> > > The error message advises to use svn cleanup, but svn cleanup 
> > > fails to unlock the WC. 
> > > (Even though it would be possible:
> > >   touch a;
> > >   svn cleanup .
> > > unlocks the WC.)
> > 
> > [[[
> > 0:% cat foo.sh 
> > #!/bin/sh
> > $svnadmin create xx
> > $svn co file:///`pwd`/xx yy
> > cd yy
> > echo a > a
> > $svn add a
> > $svn ci -m ""
> > $svn lock a
> > $svn mkdir 1
> > mv a 1   # here "forgot" to type $svn before the mv
> > $svn ci -m ""
> > $svn st -u
> > $svn cleanup 1
> > $svn cleanup .
> > $svn st -u
> > touch a;
> > $svn cleanup .
> > 0:% sh -x ./foo.sh
> > + /home/daniel/src/svn/trunk/subversion/svnadmin/svnadmin create xx
> > ++ pwd
> > + /home/daniel/src/svn/trunk/subversion/svn/svn co 
> > file:tmp/svn/xx yy
> > Checked out revision 0.
> > + cd yy
> > + echo a
> > + /home/daniel/src/svn/trunk/subversion/svn/svn add a
> > A a
> > + /home/daniel/src/svn/trunk/subversion/svn/svn ci -m ''
> > Adding a
> > Transmitting file data .
> > Committed revision 1.
> > + /home/daniel/src/svn/trunk/subversion/svn/svn lock a
> > 'a' locked by user 'daniel'.
> > + /home/daniel/src/svn/trunk/subversion/svn/svn mkdir 1
> > A 1
> > + mv a 1
> > + /home/daniel/src/svn/trunk/subversion/svn/svn ci -m ''
> > Adding 1
> > 
> > Committed revision 2.
> > subversion/svn/commit-cmd.c:156: (apr_err=200000)
> > subversion/libsvn_client/commit.c:855: (apr_err=20)
> > svn: Commit succeeded, but other errors follow:
> > subversion/libsvn_client/commit.c:873: (apr_err=155009)
> > svn: Error bumping revisions post-commit (details follow):
> > subversion/libsvn_wc/adm_ops.c:510: (apr_err=155009)
> > subversion/libsvn_wc/workqueue.c:2282: (apr_err=155009)
> > subversion/libsvn_wc/workqueue.c:2217: (apr_err=155009)
> > subversion/libsvn_wc/workqueue.c:1311: (apr_err=155009)
> > svn: Error processing post-commit work for '/tmp/svn/yy/a'
> > subversion/libsvn_wc/workqueue.c:1134: (apr_err=2)
> >

Re: contributing a script for contrib/client-side

[Daniel Shahaf]

In trunk, we have support for generating git diffs (with 'svn diff
--git'), and I believe the plan is to eventually support applying such
diffs too (via 'svn patch').  If you'd like to help with the 'svn patch'
work, please drop by the dev@ list and say hi. :-)

If you'd like to add something to contrib/, then submit that to the dev@
list; but we've deprecated that folder a while ago, and I believe we
won't accept new entries.  That just means you'll have to host the
script elsewhere.

Armands Valdmanis wrote on Fri, Oct 22, 2010 at 14:40:04 +0300:
> Hi,
>
> I would like to contribute a script for contrib/client-side.
> It takes 'git diff' generated diff (with file copying and renaming)
> and applies to working copy of SVN.
> Where do I submit it?
>
> Regards,
> Armands

Re: 1.6.13: svn cleanup fails to cleanup

[Daniel Shahaf]

Thanks, Paul.

I've tweaked the description to be slightly more verbose (we have
several 'svn cleanup' issues) and fixed the component (most probably
this is a bug in the library --- where the work is done --- not in the
thin layer that the cmdline client is).

Paul Maier wrote on Sat, Oct 23, 2010 at 01:35:25 +0200:
> filed Issue 3739
> http://subversion.tigris.org/issues/show_bug.cgi?id=3739
> 
> Paul.
> 
> 
> > -Ursprüngliche Nachricht-
> > Von: Stefan Sperling [mailto:s...@elego.de] 
> > Gesendet: Donnerstag, 21. Oktober 2010 22:13
> > An: Paul Maier
> > Cc: users@subversion.apache.org
> > Betreff: Re: 1.6.13: svn cleanup fails to cleanup
> > 
> > On Thu, Oct 21, 2010 at 09:28:43PM +0200, Paul Maier wrote:
> > > Hi everybody,
> > > 
> > > > Could you please file an issue in our tracker, linking to 
> > this thread?
> > > 
> > > To be honest, I have no idea about the meaning of all the necessary
> > > parameters like priority and DEFECT or ENHANCEMENT and 
> > target milestone,
> > > that I really would appreciate if someone could file that 
> > issue for me.
> > 
> > The bugtracker shouldn't be asking this stuff from our users,
> > but unfortunately it does :(
> > Just pick something and we'll fix it later if it needs fixing.
> > It'll be fine.
> > 
> > In this case I'd pick DEFECT, leave the priority at the default
> > and set the milestone to unscheduled. But that doesn't really matter.
> > The most important thing is that the issue gets filed in the tracker
> > so we don't forget about it.
> > 
> > Your support with filing issues will be very much appreciated.
> > We all have things to do so if the person who reported an 
> > issue also files it,
> > our community as a whole can save some valuable time.
> > See also 
> > http://producingoss.com/en/managing-volunteers.html#delegation
> > which explains the deeper reasons for why we tend to ask 
> > people to perform
> > tasks. (The short answer is that it's partly about spreading 
> > the workload,
> > and partly about building community bonds).
> > 
> > Thanks,
> > Stefan
> 

Re: SVN (numeric) error codes

[Daniel Shahaf]

Jason Heeris wrote on Tue, Oct 26, 2010 at 11:51:16 +0800:
>   1. Is there a list of these error codes anywhere? The only thing
> I've found is the documentation for a header file[2], which is not
> hugely helpful.

That header file is the canonical documentation.  Some functions
document the error codes they return on some possible error condition,
but that's all.  Basically, if you don't find the documentation in any
of the public header files, then you'll have to read the source.

Tangentially, I've been wondering at times whether a macro such as the
following:

#define svn_error_category(err) \
((err) ? ((err)->apr_err / SVN_ERR_CATEGORY_SIZE) * 
SVN_ERR_CATEGORY_SIZE : APR_SUCCESS)

svn_error_t *err = (...);
apr_status_t category = svn_error_category(err);
if (err && err->apr_err == SVN_ERR_WC_CATEGORY_START)
/* local error */;
else if (err && err->apr_err == SVN_ERR_REPOS_CATEGORY_START)
/* server-side error */;
else if (err && err->apr_err == SVN_ERR_FS_CATEGORY_START)
/* Uh-oh. */;
else if (err && err->apr_err == SVN_ERR_SVNDIFF_CATEGORY_START)
/* But I thought YOU made the backups! */;
else
...

would be useful.  (I first thought of this while reading 
svn_error_malfunction_handler_t's docstring.)  Opinions?  Use cases?

Also, there is a script, which-error.py, in ^/subversion/trunk/tools,
which converts a numeric error code into a symbolic one.

>   2. Will the error codes remain consistent with future versions of SVN?
> 

Yes, any code that has appeared in a release will be stable across all
1.x versions.

> [1] http://pysvn.tigris.org/docs/pysvn_prog_ref.html#pysvn_clienterror
> [2] http://svn.collab.net/svn-doxygen/svn__error__codes_8h.html
> 
> Thanks,
> Jason
> 
> (Please CC me on replies.)

Re: Unable to use filter command properly.

[Daniel Shahaf]

Rajnish Kumar Singh wrote on Tue, Oct 26, 2010 at 14:58:46 +0530:
> Hi,
> 
> I am trying to use svndumpfilter command in order to filter one of the folder 
> in the entire repository.
> I just want the dump of the that specific folder.
> 
> So first I created a dump file using the following command:
> svnadmin dump E:\Repositories\OR1234 > E:\OR1234.dump
> 
> I am using the following command for dump filter:
> svndumpfilter include OR1234/Test < E:\OR1234.dump > E:\123.dump
> 
> The dump is created at the given location having name 123.dump.
> 
> But when I am uploading the file to a different repository, it doesn't show 
> any thing.
> I checked the content from the svn server , it shows "there are no item to 
> show in this view"
> I used this command to load the file:
> svnadmin load E:\Repositories\OR123 < E:\123.dump

What was the output of 'svndumpfilter' and 'svnadmin load'?

Re: Unable to use filter command properly.

[Daniel Shahaf]

Rajnish Kumar Singh wrote on Tue, Oct 26, 2010 at 18:07:04 +0530:
> Hi Danial,
> I apologies for the last mail
> 

No problem.

> These are the output of 'svnadmin load' command.
> 
> And these are the output of svndumpfilter

It seems that the dumpfile is indeed empty.  I'd guess the path passed
to 'svndumpfilter include' is wrong.  (It should be relative to the root
of the repository...

Ah!  The repos is called OR1234, so the path passed to 'svndumpfilter'
should NOT include OR1234 --- just the components after that --- that
is, try 

svnadmin dump E:\Repositories\OR1234 | svndumpfilter include Test > 
E:\123.dump

.  Sorry for not noticing that sooner.)

Daniel

> 
> 
> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] 
> Sent: Tuesday, October 26, 2010 5:16 PM
> To: Rajnish Kumar Singh
> Cc: users@subversion.apache.org
> Subject: Re: Unable to use filter command properly.
> 
> Rajnish Kumar Singh wrote on Tue, Oct 26, 2010 at 14:58:46 +0530:
> > Hi,
> > 
> > I am trying to use svndumpfilter command in order to filter one of the 
> > folder in the entire repository.
> > I just want the dump of the that specific folder.
> > 
> > So first I created a dump file using the following command:
> > svnadmin dump E:\Repositories\OR1234 > E:\OR1234.dump
> > 
> > I am using the following command for dump filter:
> > svndumpfilter include OR1234/Test < E:\OR1234.dump > E:\123.dump
> > 
> > The dump is created at the given location having name 123.dump.
> > 
> > But when I am uploading the file to a different repository, it doesn't show 
> > any thing.
> > I checked the content from the svn server , it shows "there are no item to 
> > show in this view"
> > I used this command to load the file:
> > svnadmin load E:\Repositories\OR123 < E:\123.dump
> 
> What was the output of 'svndumpfilter' and 'svnadmin load'?
> 
> 

Re: Unable to use filter command properly.

[Daniel Shahaf]

Rajnish Kumar Singh wrote on Tue, Oct 26, 2010 at 18:44:59 +0530:
> Yes I have done that but getting an error message:
> .
> .
> .
> .
> Revision 3745 committed as 3745.
> Revision 3746 committed as 3746.
> Revision 3747 committed as 3747.
> Revision 3748 committed as 3748.
> svndumpfilter: Invalid copy source path '/V1.1NewSVNDirectory'

This means the subtree you're including contains a copy from outside
that subtree.  (Yes, the message could be improved.)  The filtering dies
because it doesn't have the contents of that tree in the source dump.

Use svnsync instead:

svnadmin create target
svnsync init file://.../target file://.../OR1234/Test
svnsync sync file://.../target

should tolerate that copy.

Re: Unable to use filter command properly.

[Daniel Shahaf]

Rajnish Kumar Singh wrote on Tue, Oct 26, 2010 at 19:58:26 +0530:
> > svnadmin create target
> > svnsync init file://.../target file://.../OR1234/Test
> > svnsync sync file://.../target

> Please tell me that in the given command i.e : svnsync init file://.../target 
> file://.../OR1234/Test
> file://.../target is the url of the new repository, where I want to place the 
> test file

Yes, it's a URL of the repository created in the line just above it.

Re: Corrupt node-revision, Malformed text representation

[Daniel Shahaf]

Can you provide a hex dump of what you just pasted?  At the level the
bug is occurring in, it's important for us to have the actual bytes.

000: 4865 7265 2773 2061 6e20 6578 616d 706c  Here's an exampl
010: 6520 6f66 2074 6865 2066 6f72 6d61 7420  e of the format 
020: 7765 206e 6565 642e 2020 2849 2075 7365  we need.  (I use
030: 6420 7878 6428 3129 2074 6f20 7072 6f64  d xxd(1) to prod
040: 7563 650a 7468 6973 2e29 0a  uce.this.).

Thanks,

Daniel

lcwakeman wrote on Wed, Oct 27, 2010 at 17:12:33 -0700:
> 
> Using a hex editor, i found the bad node:
> 
> id: hkh-3.0.r3/1147375416.type: file.count: 0.text: 2 18255002 89 76
> a62e181985b9f0188358520286e7f3cf de9e9fa50eb1d5cbaae57a82ddfc20e398a8ed9b
> 2-2/_ki0.props: 3 1147375350 53 0
> 113136892f2137aa0116093ignedDocument.gif.copyroot:
> 0 /..PLAIN.K 13.svn:mime-type.V 24.application/octet-stream.END.ENDREP.
> 
> Note the 48 null bytes.  It starts at byte 0x44639000 in the file.
> 
> 
> 
> lcwakeman wrote:
> > 
> > Couldn't get past the following error:
> > 
> > NodeRev Id: hkh-3.0.r3/1147375416
> >  type: file
> >  text: UNKNOWN 2 18255002 89 76 a62e181985b9f0188358520286e7f3cf
> >  prop: PLAIN 3 1147375350 53 0 113136892f2137aa0116093  
> >  
> > ignedDocument.gif
> >  copyroot: 0 /
> > Skipping text rep since it isn't present in the current rev
> > Traceback (most recent call last):
> >   File "fsfsverify.py", line 1141, in ?
> > options.dumpWindows)
> >   File "fsfsverify.py", line 591, in verify
> > raise DataCorrupt, \
> > __main__.DataCorrupt: PLAIN data is corrupted.  Expected digest
> > '113136892f2137aa0116093   
> > ignedDocument.gif', computed '113136892f2137aa0116093a524ade0b'.
> > 
> > The cpath should be:
> > 
> >  cpath: /www/themes/Sunset/images/loadSignedDocument.gif
> > 
> > Can't open the directory in the repo-browser, original error message.
> > 
> > 
> > lcwakeman wrote:
> >> 
> >> I will give it  a try and let you know.
> >> 
> >> TortoiseSVN Version info:
> >> 
> >> TortoiseSVN 1.6.11, Build 20210 - 32 Bit , 2010/09/30 20:36:44
> >> Subversion 1.6.13, 
> >> apr 1.3.8
> >> apr-utils 1.3.9
> >> neon 0.29.4
> >> OpenSSL 0.9.8o 01 Jun 2010
> >> zlib 1.2.3
> >> 
> >> The repsitory is a file system repository on a SAN disk.  I am using TSVN
> >> to keep projects syncronised on my two machines.
> >> 
> >> 
> >> 
> >> Stefan Sperling-7 wrote:
> >>> 
> >>> On Wed, Oct 27, 2010 at 11:44:06AM -0700, lcwakeman wrote:
> >>>> 
> >>>> I am getting the following error message when doing a verify using
> >>>> svnadmin. 
> >>>> I get the same errors doing a SVN  Update with TortoiseSVN.
> >>>> 
> >>>> svnadmin: Corrupt node-revision 'c74-3.0.r3/1150218126'
> >>>> svnadmin: Malformed text representation offset line in node-rev
> >>>> 
> >>>> How do I fix this?
> >>> 
> >>> Try the fsfsverify.py script:
> >>> http://svn.apache.org/repos/asf/subversion/trunk/contrib/server-side/fsfsverify.py
> >>> 
> >>> Copy the broken revision file to a temporary area.
> >>> Run fsfsverify.py -f on that copy until it reports no further errors.
> >>> Then check if the revision file works again if moved into the
> >>> repository.
> >>> Keep a backup of the broken rev just in case!
> >>> 
> >>> If you want to know more details, see:
> >>> http://subversion.tigris.org/issues/show_bug.cgi?id=3705
> >>> 
> >>> There's also been another recent post by Julian Foad about corrupt
> >>> revisions and how he fixed them:
> >>> http://svn.haxx.se/dev/archive-2010-10/0095.shtml
> >>> 
> >>> We know what the symptoms of the problem are, but we don't know the root
> >>> cause yet. To contribute a data point, could you please tell us which
> >>> server version and which client versions are you using?
> >>> 
> >>> Thanks,
> >>> Stefan
> >>> 
> >>> 
> >> 
> >> 
> > 
> > 
> 
> -- 
> View this message in context: 
> http://old.nabble.com/Corrupt-node-revision%2C-Malformed-text-representation-tp30070050p30072410.html
> Sent from the Subversion Users mailing list archive at Nabble.com.
> 

Re: Corrupt node-revision, Malformed text representation

[Daniel Shahaf]

lcwakeman wrote on Wed, Oct 27, 2010 at 13:59:28 -0700:
> The repsitory is a file system repository on a SAN disk.  I am using TSVN to
> keep projects syncronised on my two machines.

@lcwakeman: Are you using file:/// URLs?  If not, what is the version of
the server software?  What is the version of the repository? (the
contents of $REPOS_DIR/format and $REPOS_DIR/db/format)

Re: Errors in running pythong tests in make check

[Daniel Shahaf]

Hoffman, Aodhan wrote on Wed, Oct 27, 2010 at 11:14:02 -0700:
> 
> I am able to configure and build subversion fine now, after some config 
> option tweaking, but the tests still fail half way through.
> 
> I drilled down to the first failure to find out more, but based on tests.log 
> it looks like the issue is simply that the python tests are running in my 
> home directory rather than the repository directory. I'm running the tests 
> from /opt/svn/build/subversion-1.6.12/subversion, but they're looking at 
> /net/nnmx-blv-01-tmp/export/home/tx714c/. I've searched for someway to direct 
> the tests to look at the appropriate repository, /opt/svn/repo, but nothing 
> in the documentation discusses this.
> 
> Can anyone tell me where to tell make check or configure where the repository 
> is supposed to go? Thanks!
> 

The tests DO NOT run against existing repositories.  NEVER point
a Subversion on your repository until AFTER it has been tested.

The test create repositories under subversion/tests/cmdline/svn-test-work/.
They make that directory if it doesn't exist, but you can pre-create it
as a symlink if you need to.

Re: XML document structures must start and end within the same entity

[Daniel Shahaf]

David Aldrich wrote on Wed, Oct 27, 2010 at 15:48:40 +0100:
> Hi
> 
> Please will someone explain the following error message that I received while 
> updating a working copy?
> 
> "XML document structures must start and end within the same entity."
> Best regards
> David

Re: Errors in running pythong tests in make check

[Daniel Shahaf]

Hoffman, Aodhan wrote on Thu, Oct 28, 2010 at 06:51:08 -0700:
>  
> Thanks, Daniel. 
> 
> I looked and found the test repository exists, but for some reason the python 
> tests aren't targeting that directory, they're targeting my home directory, 
> and failing.
> 
> Directory 'svn-test-work' exists:
> 
>-bash-3.2$ ls -l 
> /opt/svn/build/subversion-1.6.12/subversion/tests/cmdline/svn-test-work
>total 24
>drwxr-xr-x 4 root root 4096 Oct 27 12:25 local_tmp
>drwxr-xr-x 2 root root 4096 Oct 27 09:12 repositories
>drwxr-xr-x 2 root root 4096 Oct 27 09:12 working_copies
> 
> Tests target different directory:
> 
>START: getopt_tests.py
>CMD: svnadmin create svn-test-work/local_tmp/repos --bdb-txn-nosync CMD:   
> 
>/opt/svn/build/subversion-1.6.12/subversion/svnadmin/svnadmin create 
> svn-test-work/local_tmp/repos --bdb-txn-nosync
>exited with 1
>
>svnadmin: Can't open file 
> '/net/nnmx-blv-01-tmp/export/home/tx714c/.subversion/servers': Permission 
> denied

Okay then. It's a bug; that svnadmin command should bepassed --config-dir,
whose argument should point to the config dir that the tests create.
(See svntest/main.py.)

Feel free to send a patch :-)

Re: Problems with Subversion, NFS and locking

[Daniel Shahaf]

Forwarding back to the list.

(@Christer, sorry for the duplicate)

Christer Edvartsen wrote on Thu, Oct 28, 2010 at 17:01:50 +0200:
> On Thu, 28 Oct 2010 16:05:47 +0200, Daniel Shahaf 
> wrote:
> > Christer Edvartsen wrote on Thu, Oct 28, 2010 at 15:54:45 +0200:
> >> Some weeks ago we switched from https (webdav) to svn+ssh when talking
> to
> >> our repos. Along with this switch came a locking issue. Sometimes when
> >> running svn up we get an error that some of the directories in the
> >> working
> >> copy we are trying to update is locked.
> > 
> > What is the exact error message?
> > 
> 
> It says permission denied on some file that ends in /.svn/lock, that does
> not exist. I'm not at work now so I can't get the exact message.
> 
> >> They are not locked in Subversion
> > 
> > How did you determine this?
> > 
> > (And are you talking about working copy administrative locks or about
> > the 'svn lock' kind of locks)
> 
> Well, I have tried to force the error by just doing svn up several times
> in a row (and making sure no one is actually doing any commits in between).
> Suddenly it says that some random directory is locked, even if no one has
> done anything between the svn up's.
> 
> 
> 
> -- 
> Christer Edvartsen
> http://cogo.wordpress.com/

Re: Corrupt node-revision, Malformed text representation

[Daniel Shahaf]

lcwakeman wrote on Thu, Oct 28, 2010 at 08:07:12 -0700:
> 
> Actually, the hex editor that I finally found that could read the file before
> exhausting memory wouldn't allow me to copy the hex code.  The periods in
> the example are null bytes (00).  The rest are 7 bit ascii characters, space
> is 20...
> 

Please try to use xxd then.  It's important that we see exactly (at the
byte level) what happened.  Chances are that xxd has abeen ported to
your platform.

(That's just the hex dump tool I'm used to, by the way.  Other tools may
work too.  Or even a quick-and-dirty script in C...)

> 
> 
> Daniel Shahaf-2 wrote:
> > 
> > Can you provide a hex dump of what you just pasted?  At the level the
> > bug is occurring in, it's important for us to have the actual bytes.
> > 
> > 000: 4865 7265 2773 2061 6e20 6578 616d 706c  Here's an exampl
> > 010: 6520 6f66 2074 6865 2066 6f72 6d61 7420  e of the format 
> > 020: 7765 206e 6565 642e 2020 2849 2075 7365  we need.  (I use
> > 030: 6420 7878 6428 3129 2074 6f20 7072 6f64  d xxd(1) to prod
> > 040: 7563 650a 7468 6973 2e29 0a  uce.this.).
> > 
> > Thanks,
> > 
> > Daniel
> > 
> > lcwakeman wrote on Wed, Oct 27, 2010 at 17:12:33 -0700:
> >> 
> >> Using a hex editor, i found the bad node:
> >> 
> >> id: hkh-3.0.r3/1147375416.type: file.count: 0.text: 2 18255002 89 76
> >> a62e181985b9f0188358520286e7f3cf de9e9fa50eb1d5cbaae57a82ddfc20e398a8ed9b
> >> 2-2/_ki0.props: 3 1147375350 53 0
> >> 113136892f2137aa0116093ignedDocument.gif.copyroot:
> >> 0 /..PLAIN.K 13.svn:mime-type.V 24.application/octet-stream.END.ENDREP.

Are ALL fourty-eight dots NUL bytes?  Or is the first of them a newline
(0x0A) byte?

> >> 

Thankfully, the headers always come in the same order: props, cpath,
copyfrom, copyroot.  The cpath and copyfrom path indicate that the node
has been copied.

Is that correct?  Was *ignedDocument.gif indeed copied in that revision?
>From where? (repository-relative path and revision)

Re: Not so incoherent commit

[Daniel Becroft]

On Thu, Oct 28, 2010 at 7:20 PM, Antonio Ávila wrote:

>
> Hello all, my name is Antonio Ávila and I'm an svn admin/user. I would like
> to share what happens to me yesterday with a not so incoherent tag
> operation.
>
>
>1. A team member commits changes in the trunk, at time t. (ending up
> in a revision, let's say 2).
>2. t+7 minutes later, we tag the trunk with the following command:
>
> svn cp http://someIp/svn/trunk  http://someIp/svn/tags/NewTag
>
> After some time another team member discover that the changes that should
> be in the NewTag aren't there... And the NewTag was generated from trunk,
> but revision 1 instead of 2.
>
> So, what the hell happened?
>
> Here it comes the answer.
>
> Everything looked fine with svn info and svn log, the commands were right,
> nobody made a mistake, apparently. And the commands looked fine on the
> temporal line: first the commit, then the tag operation...
>
> Looking into the access svn log in the server, what happened was that the
> tag operation were "launched but not executed" 10 minutes before the commits
> in the trunk and it was waiting for the user to write the comment. So the
> temp line was:
>
> 1.- svn cp http://someIp/svn/trunk http://someIp/svn/tags/NewTag # waiting
> in vim... (the rev info has been already taken trunk has rev 1)
> 2.- svn ci -m "some comment"  # finalizes de operation trunk has now rev 2
> 3.- write comment in vim and :x  # finalizes de operation, it doesn't
> regather the revs infos, so rev1 is copied into the tag with the comment.
>
> The "3" step, is registered with "3" time, instead of "1" time (what it's
> logical...)
>
> Well, this is an unusual situation, but it may happen to somebody in the
> future and he may not realize what happened, so here is the experience.
>   Don't leave the svn operation waiting for the comment.
>

Or craft the log message in an external file and pass that file as the
commit message.


> Also, I think that the svn client could gather the info after inserting the
> comment to avoid this situation.
>

I don't agree with this. What about the situation where the last commit *is
not* supposed to be included in the tag?

The revision used for the copy should be the revision at the time the
command was initiated (which is exactly what happened in your situation).
Otherwise, what you asked the command to operate on, and what it actually
operated on, is not the same thing.

Cheers,
Daniel B.

Re: verification of user id '' not configured

[Daniel Shahaf]

Enrique Porta wrote on Fri, Oct 29, 2010 at 08:17:54 +0200:
> Hi! i have an apache 2.2.15 server and i want to configure a secure folder.
> 
> This is my secure configuration
> 
> 

Try dropping the trailing slash.

> DAV svn
> SVNParentPath /var/lib/svn
> SVNListParentPath On
> 
> AuthType Digest

Add an AuthDigestProvider directive?

> AuthName "Private"
> AuthUserFile /etc/svn-auth-file
> AuthzSVNAccessFile /etc/svn-authz-file
> Require valid-user
>  
> 
> The svn-auth-file are create wit the htdigest command and the "Private" realm 
> .
> 
> The content of the svn-authz-file is: [/] * = r
> 
> The webrowser show me the login window, but on the server error log
> appears this:
> 
> verification of user id '' not configured
> 
> I try using the AuthType Basic with a htpasswd file and all works
> perfectly, but with the Digest no
> 
> What's the problem?
> 
> Thx ;)

Re: svn export bug in 1.6.13

[Daniel Shahaf]

http://subversion.tigris.org/issues/show_bug.cgi?id=3727

Chris Seawood wrote on Fri, Oct 29, 2010 at 10:04:17 -0700:
> Hi,
> 
> I just ran across a bug in the 1.6.13 release.
> 
> Historically, 'svn export $SVNROOT/$PATH .' has just exported the
> contents of $PATH into the current directory.  Under 1.6.13, the client
> creates a subdir named after the last directory component of $PATH and
> puts the contents there.  This change in behavior breaks some of our
> release scripts and we've been forced to downgrade to 1.6.12.
> 
> # 1.6.13
> [cseaw...@localhost foo]$ svn export --force $SVNROOT/trunk -N .
> Atrunk
> Atrunk/top.mk
> Exported revision 50141.
> 
> # Replace 1.6.13 rpm with 1.6.12
> [cseaw...@localhost foo]$ svn export --force $SVNROOT/trunk -N .
> A.
> Atop.mk
> Exported revision 50141.
> 
> - cls

Re: Observed changes didn't match count

[Daniel Shahaf]

Short version: it's a bug in Google's backend, and I can reproduce it
with neon but not with serf.

(more below)


Ryan Schmidt wrote on Fri, Oct 29, 2010 at 16:24:20 -0500:
> The Pure project is trying to switch from Subversion to Mercurial, and are 
> having trouble with svnsync.
> 
> http://groups.google.com/group/pure-lang/msg/bf588ebe14d6fb14
> 
> On revision 2967, it gives the message "Observed changes didn't match count", 
> and I get the same message when just doing an "svn log -v" on that revision:
> 
> $ svn log -v -r2967 http://pure-lang.googlecode.com/svn/trunk
> svn: Observed changes didn't match count

[[[
% $svn log -v -r2967 http://pure-lang.googlecode.com/svn/trunk --config-option 
servers:global:http-library=serf

% echo $?
0
% $svn log -v -r2967 http://pure-lang.googlecode.com/svn/trunk --config-option 
servers:global:http-library=neon
...
subversion/libsvn_ra_neon/util.c:773: (apr_err=160004)
svn: Observed changes didn't match count
% echo %?
1
% ./tools/dev/which-error.py 160004
00160004  SVN_ERR_FS_CORRUPT
% $svn --version | head -n2
svn, version 1.7.0 (dev build)
   compiled Oct 27 2010, 15:38:01
% 
]]]

> $
> 
> "svn log" without "-v" works fine, as does "svn diff".
> 
> Google searching for this error message yields only one other occurrence, 
> which was not really solved.
> 
> I'm unsure what we should try from here. Possibly this error is unique
> to Google Code's Subversion backend,

The error code confirms your suspicion.  Furthermore, the word
"Observed" doesn't appear in Subversion's source code.

> but still I would have expected
> others to have run into it. Any suggestions?
> 
> 
> 

Re: Observed changes didn't match count

[Daniel Shahaf]

Ryan Schmidt wrote on Fri, Oct 29, 2010 at 18:26:25 -0500:
> On Oct 29, 2010, at 17:11, Daniel Shahaf wrote:
> 
> > Short version: it's a bug in Google's backend, and I can reproduce it
> > with neon but not with serf.
> 
> > % $svn log -v -r2967 http://pure-lang.googlecode.com/svn/trunk 
> > --config-option servers:global:http-library=serf
> > 
> > % echo $?
> > 0
> > % $svn log -v -r2967 http://pure-lang.googlecode.com/svn/trunk 
> > --config-option servers:global:http-library=neon
> > ...
> > subversion/libsvn_ra_neon/util.c:773: (apr_err=160004)
> > svn: Observed changes didn't match count
> > % echo %?
> > 1
> > % ./tools/dev/which-error.py 160004
> > 00160004  SVN_ERR_FS_CORRUPT
> > % $svn --version | head -n2
> > svn, version 1.7.0 (dev build)
> >   compiled Oct 27 2010, 15:38:01
> > % 
> 
> I agree using serf instead of neon makes the error message go away.
> But it also doesn't actually show the list of files affected by the
> commit like it should. See "svn diff --summarize -r2967" for all the
> files that should be shown there.
> 

More specifically, it behaves as if there are no relevant revisions to show:

[[[
% $svn log -vr100 http://svn.eu.apache.org/repos/asf/subversion


% $svn log -vr100 http://svn.eu.apache.org/repos/asf

r100 | yonik | 2010-09-22 16:48:10 +0200 (Wed, 22 Sep 2010) | 1 line
Changed paths:
   M /lucene/dev/trunk/solr/CHANGES.txt
   M /lucene/dev/trunk/solr/src/java/org/apache/solr/search/FunctionQParser.java
   M /lucene/dev/trunk/solr/src/java/org/apache/solr/search/QueryParsing.java
   M 
/lucene/dev/trunk/solr/src/test/org/apache/solr/search/FunctionQParserTest.java
   M 
/lucene/dev/trunk/solr/src/test/org/apache/solr/search/function/TestFunctionQuery.java

SOLR-2128: full param substitution for function queries


% 
]]]

There shouldn't be any authz restrictions on this repository, right?

> Also, even when I change http-library to serf in the servers config
> file, svnsync still shows the "Observed changes didn't match count"
> error. Does svnsync not use this library setting?
> 

Examining the code shows that the apr_hash_t *config is passed down to
svn_ra_open4(), and upon trying I cannot reproduce this:

[[[
% $svnsync init http://localhost:8081/t/{r2,r1}
DBG: ra_loader.c: 493: vtable='Module for accessing a repository via WebDAV 
protocol using serf.' url='http://localhost:8081/t/r2'
DBG: ra_loader.c: 493: vtable='Module for accessing a repository via WebDAV 
protocol using serf.' url='http://localhost:8081/t/r1'
Copied properties for revision 0.
% mkdir cfg
% cat > cfg/servers
[global]
http-library = neon
% $svnsync sync http://localhost:8081/t/r2 --config-dir cfg
DBG: ra_loader.c: 493: vtable='Module for accessing a repository via WebDAV 
protocol using Neon.' url='http://localhost:8081/t/r2'
DBG: ra_loader.c: 493: vtable='Module for accessing a repository via WebDAV 
protocol using Neon.' url='http://localhost:8081/t/r1'
Transmitting file data 
Committed revision 1.
Copied properties for revision 1.
]]]

> 
> >> I'm unsure what we should try from here. Possibly this error is unique
> >> to Google Code's Subversion backend,
> > 
> > The error code confirms your suspicion.  Furthermore, the word
> > "Observed" doesn't appear in Subversion's source code.
> 
> I suppose we should report the problem to Google Code and hope they
> can uncorrupt the repository somehow?

Yes.  SVN_ERR_FS_CORRUPT justifies reporting this to the Google admins.

> Apparently a couple dozen
> subsequent revisions see the same error, through r2993.
> 

Re: syvnsync or svnadmin dump?

[Daniel Shahaf]

Campbell Allan wrote on Tue, Nov 02, 2010 at 10:49:38 +:
> The dump/load approach is also useful if you want to prune the repository 
> whilst moving it. ie, if you're splitting it into several new repositories or 
> prermanently removing certain paths.

You can also achieve some of these with svnsync --- e.g., if you set
svnsync to access the source repository as a user who doesn't have authz
permissions to read all of it, or if you set svnsync to mirror a subdir
of the original repository into a new repository.

Re: German translation of "svn help st" is not showing, although provided in de.po

[Daniel Shahaf]

Paul Maier wrote on Wed, Nov 03, 2010 at 07:33:32 +0100:
> Hello,
> 
> Obverved:
> All svn output, error messages, online help comes in German.
> But "svn help status", "svn help switch" and "svn help update" 
> print in English.
> 
> Expected:
> "svn help status", "svn help switch" and "svn help update" 
> should print in German.
> 
> The translation exists in the repository:
> http://svn.apache.org/repos/asf/subversion/trunk/subversion/po/de.po,
> lines 9493 - 9587 (svn help status),

First, this is trunk and not /branches/1.6.x or /tags/1.6.13.

Second, it's possible that the message has been updated but not the
translation.  Based on your description (all messages --- including
Subversion-specific message strings --- are in German, except these
three), I suspect that is the case.

There's not much you can do, other than get someone to update the
translations --- or jumping in and doing that yourself!

Daniel
(there is a "Translations" top-level section in the Community Guide that
explains how you can help (if you want to))

> lines 9626 - 9667 (svn help switch) and
> lines 9723 - 9769 (svn help update).
> 
> These are the binaries I use:
> http://alagazam.net/svn-1.6.13/Setup-Subversion-1.6.13.msi
> 
> Thank you for having a look into that.
> 
> Greetings,
>   Paul.
>  
> 

Re: Inaccurate "Updated to revision" when updating multiple targets

[Daniel Shahaf]

Ryan Schmidt wrote on Wed, Nov 03, 2010 at 04:48:21 -0500:
> Minor bug report in the way Subversion prints output when I'm updating
> multiple targets, some of which have changes and some of which do not.
> 
> Imagine I have directories a, b and c, and I ask Subversion to update
> all three, but only b has changes. The output received with Subversion
> 1.6.13 on Mac OS X 10.6.4 is:
> 
> 
> $ svn up a b c
> At revision 2.
> Ab/something
> Updated to revision 2.
> Updated to revision 2.
> $
> 

Same with trunk:

% $svn up A mu B
At revision 2.
 U   mu
Updated to revision 2.
Updated to revision 2.

> 
> The expected output is:
> 
> 
> $ svn up a b c
> At revision 2.
> Ab/something
> Updated to revision 2.
> At revision 2.
> $
> 

+1

> 
> Looking in subversion/svn/notify.c it looks like it prints "Updated
> to" or "At" depending on whether nb->received_some_change, so that
> variable should be reset when moving to a new target.
> 

+1.

(Or should the 'received_some_change' logic live in the library (in the
generation of notifications)?  I haven't thought much about that.)

> 

Bottom line: agreed that there is a bug here.  If you (or anyone else)
wants to file an issue or send a patch for that, go ahead. :-)

Re: XML document structures must start and end within the same entity

[Daniel Shahaf]

Johan Corveleyn wrote on Wed, Nov 03, 2010 at 15:23:51 +0100:
> On Thu, Oct 28, 2010 at 3:09 PM, Daniel Shahaf  
> wrote:
> > [empty reply]
> 
> Huh? Was this mail supposed to contain an answer, Daniel?
> 

No; it was accidentally sent.

Re: mergeinfo not inherrited when I thought it should

[Daniel Shahaf]

Johan Corveleyn wrote on Wed, Nov 03, 2010 at 10:17:34 +0100:
> (the upcoming 1.7 release will improve the situation a bit, IIUC: the
> not-affected-subtrees will no longer have their mergeinfo updated all
> the time, only if they are affected by the merge).

That surprised me a little, but a quick test with current trunk[1]
confirms:

% cd ~/src/svn/16x/
% $svn merge -c N ../trunk
...
% $svn pg -vR svn:mergeinfo . | grep Properties
Properties on '.':
Properties on 'subversion/tests/cmdline/merge_tests.py':
Properties on 'CHANGES':
% $svn st -q
 M  .
M   subversion/include/svn_client.h
C   subversion/tests/cmdline/export_tests.py
C   subversion/svn/export-cmd.c
M   subversion/libsvn_client/export.c
% $svn st -q | egrep 'CHANGES|merge_tests'
% 

Nice.

Daniel

[1] I'm using a build from the performance branch as my "current trunk"
build these days.

Re: mergeinfo not inherrited when I thought it should

[Daniel Shahaf]

Johan Corveleyn wrote on Wed, Nov 03, 2010 at 17:18:54 +0100:
> On Wed, Nov 3, 2010 at 3:45 PM, Daniel Shahaf  wrote:
> > Johan Corveleyn wrote on Wed, Nov 03, 2010 at 10:17:34 +0100:
> >> (the upcoming 1.7 release will improve the situation a bit, IIUC: the
> >> not-affected-subtrees will no longer have their mergeinfo updated all
> >> the time, only if they are affected by the merge).
> >
> > That surprised me a little, but a quick test with current trunk[1]
> > confirms:
> 
> Yes, it's kind of easy to miss, because there is no explicit issue in
> the issue tracker for this AFAIK. But I vaguely remember some mail
> threads on the dev-list about this, and saw it mentioned in the
> description of another issue about mergeinfo ([1]).

There's quite a bit of traffic about mergeinfo.  I try to follow the
developments to some degree, but I missed (or forgot) about this change.

> This refers to
> revision r878767 ([2]), which is apparently the reintegration of a
> feature branch "subtree-mergeinfo", which was made specifically for
> developing this feature.
> 

Thanks for the digging!

> Since this is quite a big issue for a lot of users, it's important not
> to forget about this change when the time comes to write the release
> notes for 1.7. Maybe it should be mentioned on the roadmap page (as
> one of the finished items), or an issue should be created in the issue
> tracker?
> 

(without expressing an opinion as to which option is preferable,) another
option is to create a stub section in
/site/publish/docs/release-notes/1.7.html.

btw, I think there have been more release-notes-worthy merge-tracking
changes than just this one.

> Cheers,
> -- 
> Johan
> 
> [1] http://subversion.tigris.org/issues/show_bug.cgi?id=3577
> [2] http://svn.apache.org/viewvc?view=revision&revision=878767

Re: Trying to build Subversion on Visual Studio 2008

[Daniel Shahaf]

PGSEM Contractor 4 wrote on Wed, Nov 03, 2010 at 17:01:30 +:
> When I get to trying to run Visual Studio's command line (devenv) I can't 
> locate the subversion_vcnet.sln file, nor the earlier subversion_msvc.dsw 
> file.
> 
> What step(s) have I missed?
> 

Running gen-make.py.

Re: Can you hear me now?

[Daniel Shahaf]

Andy Levy wrote on Wed, Nov 03, 2010 at 15:04:29 -0400:
> On Wed, Nov 3, 2010 at 14:54, Andersen, Krista  
> wrote:
> > Hi,
> >
> > I tried posting a question to this users list last night and I still don't 
> > see it here (nor any responses).  Am I being blocked?  Am I being too 
> > impatient?  Will I simply not see my own posts until someone replies?
> 
> Your own posts are not sent back to you. Your post did appear on the
> list; there are several list archives online you can use to verify
> this.
> 
> Because this is a free, strictly volunteer, wide-open mailing list,
> you are not guaranteed to get answers to your questions - or any
> response at all, for that matter. That said, the community usually
> does a good job of tackling questions, assuming they're relevant,
> understandable, and well-written.
> 

In this case, my impression is that (1) the question belongs more on the
httpd mailing lists than on the subversion mailing lists; (2) the OP
(Krista) can probably answer most of them by herself.

(file(1), manpages and the excellent httpd docs are your friends; have
you consulted them?)

> Another thing that would help tremendously is to eliminate the
> miles-long disclaimer on your emails, or use another account which
> does not tack it on automatically. The validity/enforceability of
> these disclaimers is dubious at best to begin with, and when posted to
> public-access mailing lists which are archived and trivially searched
> via Google, cannot have posts deleted from them, and are completely
> unrelated to your company's line of business, are completely
> pointless.

one's own posts Re: Can you hear me now?

[Daniel Shahaf]

Daniel Shahaf wrote on Wed, Nov 03, 2010 at 21:17:09 +0200:
> Andy Levy wrote on Wed, Nov 03, 2010 at 15:04:29 -0400:
> > On Wed, Nov 3, 2010 at 14:54, Andersen, Krista  
> > wrote:
> > > I tried posting a question to this users list last night and
> > > I still don't see it here (nor any responses).  Am I being
> > > blocked?  Am I being too impatient?  Will I simply not see my own
> > > posts until someone replies?
> > 
> > Your own posts are not sent back to you.

Are you sure?  I certainly get all my own posts via the list.

Re: Moving repository across servers : storage format problem

[Daniel Shahaf]

Did you checkout over file:/// ?

Andy Levy wrote on Thu, Nov 04, 2010 at 14:04:23 -0400:
> On Thu, Nov 4, 2010 at 13:24, Gingko  wrote:
> > Hello,
> >
> > I am trying to move a Subversion repository from one server (running Windows
> > XP Professional SP3) to another (running Linux Debian 5 Lenny)
> >
> > The first server (on Windows) actually has Subversion installed through a
> > VisualSVN GUI interface.
> > The second server has Subversion version 1.5.1 installed from Debian packet
> > (as it is the latest stable version provided by Debian).
> >
> > I first tried to just copy the directory from the first computer to the
> > second one, and check if it works.
> > But unfortunately, when trying to checkout the repository content, I got the
> > following error message :
> >
> > "Format de stockage attendu entre '1' et '3' ; format trouvé '4'"
> >
> > (so in English, something like "Expected storage format between '1' and '3',
> > found format '4'")
> >
> > Seeing that, I completely deleted the repository that I just copied, and I
> > tried again, creating a new empty repository and moving using "svnadmin
> > dump" on the first computer, and "svnadmin load" on the second one.
> >
> > But, more surprisingly, when trying to checkout, I still get this very same
> > error message  !!!???
> >
> > So I ask the question :
> > How can I move repositories between computers running different OS,
> > different versions of Subversion and different repository formats ?
> 
> This is precisely what svnadmin dump/load is designed to address. So,
> step by step, how exactly did you do this? And are you certain that
> you have only one version of all the Subversion libraries installed on
> your Debian server?

Re: Trying to build Subversion on Visual Studio 2008

[Daniel Shahaf]

PGSEM Contractor 4 wrote on Thu, Nov 04, 2010 at 11:33:40 +:
> However when I try to compile the source it complains that it can't find 
> apr.h. I've rooted around subversion-deps-1.6.13.zip and found that there are 
> files named apr.h.in, apr.hnw and apr.hw.
> 
> What do I need to do to get apr.h?

Build APR and APR-Util.

Re: Listing excluded items

[Daniel Shahaf]

Neil Bird wrote on Thu, Nov 04, 2010 at 16:23:21 +:
> Around about 04/11/10 10:16, Giulio Troccoli typed ...
>> Maybe you could try the ls command with a URL
>
>   Well, yes, if I 'ls' the repo I'm going to see what should be there.
>
>   What I wanted to know was if there was any local indication;  something 
> that would show me while I was offline.

The 'entries' file should list them.  It should be possible to hack
together a quick parser if needed (e.g., gut the change-svn-wc-format.py
script).

For 1.7, it will be:
sqlite3 .svn/wc.db .dump | grep exclude
give or take.

Re: svnserve.exe (Win32) using 2GB of memory and then crashing?

[Daniel Shahaf]

Chris Tashjian wrote on Thu, Nov 04, 2010 at 19:01:53 -0400:
> We've been having this problem for a while now (since late in the 1.5  
> releases and now right up thru 1.6.13) and I'm at a loss as to what the  
> cause is.
>
> We have a single repository with approximately 129K revisions.
>
> SVNServe.exe's memory usage, numerous times a day, spins up to about 2GB  
> and then the svn server becomes unresponsive.  Clients get:
>
>svn: Can't connect to host 'svn': No connection could be made
>because the target machine actively refused it.
>
> When this happens, I have to restart svnserve (sometimes force-killing  
> it in task manager first).
>
> I used to use CollabNet's windows distribution, but recently switched to  
> SlikSVN and we're still experiencing the problem.  I'm tempted to move  
> the server to a 64-bit box and try SlikSVN's 64-bit client, but I feel  
> that that may only be a band-aid and we'll start hitting the 4GB wall.
>
> There's no good logging for SVN, so I can't even seem to dig up an error...
>

Try 'svnserve --log-file' ?

> Does anyone have any suggestions?
>

What kind of filesystem does the repository have?

* FSFS or BDB?
* What version of svnadmin created it?
* Have you run 'svnadmin upgrade'?

Does the problem only occur with one backend kind?

> Thanks,
> Chris

Re: svnserve.exe (Win32) using 2GB of memory and then crashing?

[Daniel Shahaf]

Chris Tashjian wrote on Thu, Nov 04, 2010 at 19:34:37 -0400:
>
> On 11/4/2010 7:23 PM, Daniel Shahaf wrote
>> Try 'svnserve --log-file' ?
>
> Been there, done that.  Endless logging of svn operations, but not a  
> single stacktrace or error.
>

AFAIK we do log errors in svnserve.

>
>> What kind of filesystem does the repository have?
>>
>> * FSFS or BDB?
>> * What version of svnadmin created it?
>> * Have you run 'svnadmin upgrade'?
>
> Filesystem should be FSFS, the default when I created it back with 1.4.x.
>
> I have run "svnadmin upgrade" a couple times (not in a while though, I  
> ran it the last time it as required w/1.5 or 1.6).  I've never attempted  
> to dump and reload the repository.
>

'svnadmin upgrade' was never required.  What does $REPOS/db/format say?

>
>> Does the problem only occur with one backend kind?
>
> What do you mean "one backend kind"?

With FSFS but not with BDB, or vice-versa.  Or, for that matter, with
FSFS format-4 but not with FSFS format-3 (i.e., with/without
--pre-1.6-compatible).

> 

I'm just shooting in the dark.

Re: svnserve.exe (Win32) using 2GB of memory and then crashing?

[Daniel Shahaf]

Chris Tashjian wrote on Thu, Nov 04, 2010 at 20:07:02 -0400:
>
>> AFAIK we do log errors in svnserve.
>
> I just looked at the current 540MB log file and the word "Error" only  
> appears in file names committed to the repository.  I don't see a single  
> stacktrace in there either.  So maybe svnserve is just hanging w/o error?
>

Maybe.  Fire a debugger and check?

>> 'svnadmin upgrade' was never required.
>
> I ran it when we moved to 1.5 to take advantage of svn:mergeinfo.  I  
> just ran it again, it took about a second to run.
>

So you just changed the environment a little.  Okay...

>
>> What does $REPOS/db/format say?
>
> "5"
>

Wrong format file.  Please look at the file 'db/format', not the file
'format'.  Thanks.

>
>> With FSFS but not with BDB, or vice-versa.  Or, for that matter, with
>> FSFS format-4 but not with FSFS format-3 (i.e., with/without
>> --pre-1.6-compatible).
>
> Ah, I haven't tried to mess around with the formats at all.  Granted, I  
> don't know if I just bumped it to "5" with that svnadmin upgrade, or if  
> it was already there.  The output from the command said the repository  
> had been upgraded, not that it was already upgraded (but I don't know if  
> it'd say that).

It's output is the same in both cases (whether or not it found the
 filesystem already upgraded) --- and, yes, that's a (minor) bug.

Re: apache coredump in mod_dav_svn

[Daniel Shahaf]

Rob Kooper wrote on Wed, Nov 03, 2010 at 22:54:57 -0500:
> I'm getting a core dump in mod_dav_svn, here is the backtrace:
> 
...
> 
> This seems to happen when a propfind is performed on the parentpath of my 
> repository. Running the following curl makes the coredump happen:
> 
> curl --request PROPFIND --header "Depth: 1" https://host/svn/
> 
> The section from apache.conf is:
> 
> 
> # Uncomment this to enable the repository
> DAV svn
> 
> # Set this to the path to your repository
> SVNParentPath /home/svn
> SVNListParentPath on
> 
> 
> Is this a known issue or do I have something wrong.

Thanks for the report.  I can reproduce it with current trunk:

(gdb) bt
#0  0xb749d640 in svn_stringbuf_dup (original_string=0x0, pool=0x8402518)
at subversion/libsvn_subr/svn_string.c:509
#1  0xb751556e in walk (params=0xbfce3780, depth=1, response=0xbfce37d0)
at subversion/mod_dav_svn/repos.c:4139
#2  0x0809f94f in dav_method_propfind (r=0x8402558) at mod_dav.c:2064
#3  0x080a362c in dav_handler (r=0x8402558) at mod_dav.c:4649
#4  0x0807d9f9 in ap_run_handler (r=0x8402558) at config.c:158
#5  0x08080d7e in ap_invoke_handler (r=0x8402558) at config.c:376
#6  0x080988d6 in ap_process_request (r=0x8402558) at http_request.c:282
#7  0x08095858 in ap_process_http_connection (c=0x83fe6e0) at http_core.c:190
#8  0x08084eb9 in ap_run_process_connection (c=0x83fe6e0) at connection.c:43
#9  0x080beb5d in child_main (child_num_arg=) at 
prefork.c:662
#10 0x080bee27 in make_child (s=0x834f098, slot=0) at prefork.c:707
#11 0x080bf532 in ap_mpm_run (_pconf=0x834a0a8, plog=0x838e1b8, s=0x834f098) at 
prefork.c:983
#12 0x0806a490 in main (argc=Cannot access memory at address 0x0) at main.c:739

mod_dav_svn segfaults upon PROPFIND to the SVNParentPath location (was: Re: apache coredump in mod_dav_svn)

[Daniel Shahaf]

Moving to d...@.  (Please drop users@ from follow-ups.)

Summary: segfault in mod_dav_svn with PROPFIND at the SVNParentPath
location, reproducable with trunk.

Daniel Shahaf wrote on Fri, Nov 05, 2010 at 14:03:26 +0200:
> Rob Kooper wrote on Wed, Nov 03, 2010 at 22:54:57 -0500:
> > I'm getting a core dump in mod_dav_svn, here is the backtrace:
> > 
> ...
> > 
> > This seems to happen when a propfind is performed on the parentpath of my 
> > repository. Running the following curl makes the coredump happen:
> > 
> > curl --request PROPFIND --header "Depth: 1" https://host/svn/
> > 
> > The section from apache.conf is:
> > 
> > 
> > # Uncomment this to enable the repository
> > DAV svn
> > 
> > # Set this to the path to your repository
> > SVNParentPath /home/svn
> > SVNListParentPath on
> > 
> > 
> > Is this a known issue or do I have something wrong.
> 
> Thanks for the report.  I can reproduce it with current trunk:
> 
> (gdb) bt
> #0  0xb749d640 in svn_stringbuf_dup (original_string=0x0, pool=0x8402518)
> at subversion/libsvn_subr/svn_string.c:509
> #1  0xb751556e in walk (params=0xbfce3780, depth=1, response=0xbfce37d0)
> at subversion/mod_dav_svn/repos.c:4139
> #2  0x0809f94f in dav_method_propfind (r=0x8402558) at mod_dav.c:2064
> #3  0x080a362c in dav_handler (r=0x8402558) at mod_dav.c:4649
> #4  0x0807d9f9 in ap_run_handler (r=0x8402558) at config.c:158
> #5  0x08080d7e in ap_invoke_handler (r=0x8402558) at config.c:376
> #6  0x080988d6 in ap_process_request (r=0x8402558) at http_request.c:282
> #7  0x08095858 in ap_process_http_connection (c=0x83fe6e0) at http_core.c:190
> #8  0x08084eb9 in ap_run_process_connection (c=0x83fe6e0) at connection.c:43
> #9  0x080beb5d in child_main (child_num_arg=) at 
> prefork.c:662
> #10 0x080bee27 in make_child (s=0x834f098, slot=0) at prefork.c:707
> #11 0x080bf532 in ap_mpm_run (_pconf=0x834a0a8, plog=0x838e1b8, s=0x834f098) 
> at prefork.c:983
> #12 0x0806a490 in main (argc=Cannot access memory at address 0x0) at 
> main.c:739
> 

Re: Only two Windows binary distribution support SASL encryption?

[Daniel Shahaf]

That seems like reasonable information to add to the download page.

John Alan Belli wrote on Fri, Nov 05, 2010 at 16:23:51 -0400:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> I have the Win 2003 server set up with SASL and encryption, as
> stated earlier this week. 
>  
> The relevant portion of svnserve.conf:
>  [sasl]
> use-sasl = true
> min-encryption = 128
> max-encryption = 256
>   
> and svn.conf:
> pwcheck_method: auxprop
> auxprop_plugin: sasldb
> mech_list: DIGEST-MD5
> sasldb_path: C:\Subversion\conf\sasldb
>  
> I tried all the Windows binaries on the binaries download page.
> Only SlikSVN and WANdisco are able to talk to the repository. All
> other fail with "svn: Cannot negotiate authentication mechanism"
>  
>  
>  JAB
> - -- 
> John Alan Belli  jabe...@pobox.com   http:// coming soon
> (_...@___#PGP DH/DSS Key ID: 0x9F9A5233  RSA Key ID: 0xFD7399CD
> U/~   O-   Available by finger and on various keyservers
>  
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.12 (MingW32) - WinPT 1.4.2
> Charset: UTF-8
> 
> iEYEARECAAYFAkzUZ60ACgkQ2IsOhZ+aUjPytgCg23vT0IeZf/faepHaltdP7Uxa
> BWEAoJz3/TUyINwgpoLYGLwtkhR1jx28
> =xTV3
> -END PGP SIGNATURE-

Re: SVN mixed public\restricted access, please help!

[Daniel Shahaf]

1. There is a "$authenticated" keyword in addition to "$anonymous".  Might help.

2. Bugfix that will be in 1.6.14: unreadable directories will not appear
in their parent directory's list of children, both in 'svn ls' and in
the listing that appears when an http:// repository is accessed in
a browser.  It's in the neighbourhood, though not directly related to
what you need.

Shaun Martin wrote on Tue, Nov 09, 2010 at 13:32:46 -0500:
> Hi All, 
> 
> Ok I am trying to achieve a repository that at its base level everyone has
> read-only access without a username. But then at subsequent levels I would
> like to remove their access so they have none. I thought this could be
> accomplished with 1.6 with the addition of "~" and "$anonymous" but I have
> yet been able to get a working configuration.
> 
> First off I tried setting up my apache just like this for my repo.
>Code: 
>   
>   DAV svn 
>   SVNParentPath /var/svn
> 
>   # our access control policy
>   AuthzSVNAccessFile /path/to/access/file
> 
>   # try anonymous access first, resort to real
>   # authentication if necessary.
>   Satisfy Any 
>   Require valid-user
> 
>   # how to authenticate a user
>   AuthType Basic 
>   AuthName "Subversion repository"
>   AuthUserFile /path/to/users/file
>  
> 
> with this in my SVNAccessFile
> 
>Code: 
>   [openclinica:/subdir]
> @clients = rw 
> @svn-admin = rw 
> 
> [/] 
> @svn-admin = rw 
> 
> I could not achieve a non authenticated user to gain access unless i added
> either "* = r" or "$anonymous = r" to the [/] in the access file. so now my
> file looks like this.
> 
>Code: 
>   [openclinica:/subdir]
> @clients = rw 
> @svn-admin = rw 
> 
> [/] 
> @svn-admin = rw 
> $anonymous = r 
> 
> Now I try to remove access to my subdir for the anonymous users by adding
> "~$anonymous = r" so my file now looks like this.
> 
>Code: 
>   [openclinica:/subdir]
> @clients = rw 
> @svn-admin = rw 
> ~$anonymous = r 
> 
> [/] 
> @svn-admin = rw 
> $anonymous = r 
> 
> which apparently does nothing as anonymous users can still access my subdir
> and it does not force anyone to login.
> 
> So then I tried the following.
> 
>Code: 
>   [openclinica:/subdir]
> @clients = rw 
> @svn-admin = rw 
> $anonymous = 
> 
> [/] 
> @svn-admin = rw 
> $anonymous = r 
> 
> Which did not allow anonymous users to access my subdir, unfortunately it
> does not allow my authenticated users to access the subdir either.
> 
> I have tried all these configuration with the "Satisfy Any" in apache
> enabled and disabled. Please help!!
> 
> This was posted on svnforum.org
> http://www.svnforum.org/2017/viewtopic.php?p=32748#32748
> 
> Thanks, 
> Shaun
> --  
> Shaun Martin
> Systems Administrator
> Akaza Research
> smar...@akazaresearch.com
> Office: (781) 547-8413
> www.akazaresearch.com 
> www.openclinica.org 
> Open Source Platform for Clinical Research
> 
> 

Re: svnsync checksum error

[Daniel Shahaf]

Edward Ned Harvey wrote on Sat, Nov 06, 2010 at 20:29:18 -0400:
> > From: opensrcguru [mailto:opensrcg...@gmail.com]
> > 
> > Today, the sync process started failing on 1 repo (all others were
> > unaffected) on both r/o copies at the exact same time/same revision
> > with errors similar to the following...
> > 
> > Transmitting file data .svnsync: Base checksum mismatch on
> > '/path/to/file/foo/bar':
> >expected:  2f2e025c4c4855e7466799a877b3e23d
> >  actual:  272214b9518d352e16e7eeceeb22f573
> 

Can you compare the contents of /path/to/file/foo/bar between the master
and mirror, as of the last revision successfully synced to the mirror?

If you create a fresh mirror and svnsync it, from r0 to that revision,
does the file /path/to/file/foo/bar in the fresh mirror differ from the
one in the master?

What versions of everything are you using?

What format are the repositories?  (What are the contents of the files
$REPOS_DIR/db/fs-type and $REPOS_DIR/db/format?)

> I recently had the same problem.  I never found any cause for it, but
> I did manage to deal with it somewhat better than you did.  On the
> master, I did svnadmin hotcopy, then I tarred up the backup and sent
> it to the slave, and extracted it.  I had to configure the slave hook
> scripts, and the revprop rev 0 properties, and then I was able to
> svnsync to the slave again.  The main point of difference ... No need
> to wait for 65k commits to transfer.  Since it's starting from
> a recent backup, it's enormously faster.
> 
> 
> 

Re: locking down access to a repository

[Daniel Shahaf]

opensrcguru wrote on Tue, Nov 09, 2010 at 14:03:32 -0600:
> I figured it out.  You can't  (or refuse)  to read. Quit your job and
> apply at wal-mart as a greeter.
> 

This tone is completely unnecessary, Terry.

Re: Manually removing corrupted TXNs

[Daniel Shahaf]

kmra...@rockwellcollins.com wrote on Wed, Nov 10, 2010 at 09:01:08 -0600:
> I finally wrote a simple script to remove dead transactions older than 1 
> week.  It worked
> great, but there appears to be a few old TXNs that are somehow 
> corrupted/malformed.
> 
> Any issues with just going into the fsfs db/transactions directory and 
> removing
> the offending named directory manually?
> 

I'm not sure.  Does 'svnadmin rmtxns' not work?

> Using fsfs svn 1.6.12 and mod_dav_svn on windows.  (Some of
> these transactions were probably created with older versions.)
> 
> All 21k revisions verify fine, but svnlook does report an error:
> 
> H:\svn\repos>svnadmin lstxns the_repo
> 77-1
> 
> H:\svn\repos>svnlook info the_repo -t 77-1
> svnlook: Malformed file
> 
> 
> H:\svn\repos>dir 787_displays_repo\db\transactions\77-1.txn
>  Directory of H:\svn\repos\the_repo\db\transactions\77-1.txn
> 
> 05/21/2008  10:59 AM  .
> 05/21/2008  10:59 AM  ..
> 05/21/2008  10:59 AM 0 changes
> 05/21/2008  10:59 AM 4 next-ids
> 05/21/2008  10:59 AM   153 node.0.0
> 05/21/2008  10:59 AM 0 props
> 05/21/2008  10:59 AM 0 rev
> 05/21/2008  10:59 AM 0 rev-lock
>6 File(s)157 bytes
>2 Dir(s)  64,575,000,576 bytes free
> 
> H:\svn\repos>type the_repo\db\transactions\77-1.txn\next-ids
> 0 0
> 
> H:\svn\repos>type the_repo\db\transactions\77-1.txn\node.0.0
> id: 0.0.t77-1
> type: dir
> pred: 0.0.r77/37863
> count: 78
> text: 77 37752 98 98 55b9c9a8be05671d26f80ae39de656c0
> cpath: /
> copyroot: 0 /
> is-fresh-txn-root: y
> 
> I have some other repos with transactions with similar errors
> and also other ones with slightly different errors.
> 
> The repos themselves verify, dump, and load fine, the
> data itself is stored on an enterprise SAN.  No filesystem
> corruption found.
> 
> The other errors:
> 
> svnlook: Can't open file 
> 'H:\svn\repos\the_repo2\db\transactions\2700-2.txn\pr
> ops': The system cannot find the file specified.
> 
> H:\svn\repos>dir the_repo2\db\transactions\2700-2.txn
>  Directory of H:\svn\repos\the_repo2\db\transactions\2700-2.txn
> 
> 11/27/2007  02:08 AM  .
> 11/27/2007  02:08 AM  ..
>0 File(s)  0 bytes
>2 Dir(s)  64,568,352,768 bytes free
> 
> 
> svnlook: Corrupt node-revision '0.0.t33407-bp8'
> svnlook: Missing id field in node-rev
> 
> H:\svn\repos>dir the_repo3\db\transactions\33407-bp8.txn
>  Directory of H:\svn\repos\the_repo3\db\transactions\33407-bp8.txn
> 
> 11/06/2009  12:46 PM  .
> 11/06/2009  12:46 PM  ..
> 11/06/2009  12:46 PM 0 changes
> 11/06/2009  12:46 PM 4 next-ids
> 11/06/2009  12:46 PM   182 node.0.0
> 11/06/2009  12:46 PM   216 props
>4 File(s)402 bytes
>2 Dir(s)  64,568,352,768 bytes free
> 
> (next-ids and node.0.0 just contain nulls.  props contains the actual 
> property data.)
> 
> thanks!
> Kevin R.

Re: Sparse updates

[Daniel Shahaf]

Klaus Ganser wrote on Tue, Nov 09, 2010 at 21:19:24 -0800:
> Hello,
> 
> I have a simple feature request for the svn update command, so I'd
> like some feedback on the utility of this feature.  In the past, I've

Sounds useful to me.

> wanted to perform a sparse checkout of several different parts of a
> repository, so I've started by checking out the root using
> --depth=empty:
> 
> svn co --depth=empty svn+ssh://svn.example.com/trunk/ trunk/
> 
> From here, if I wanted to download the contents of /trunk/a/b/ and
> /trunk/c/d/e/ without any extraneous files or directories, I would
> have to first check out all of the intermediate directories in the two
> paths explicitly:
> 
> svn up --depth=empty trunk/a/ trunk/c/
> svn up --depth=empty trunk/c/d/
> svn up trunk/a/b/ trunk/c/d/e/
> 
> What I'm proposing is that svn update have a --parent flag that would
> perform these intermediate updates as necessary for the requested
> update paths, much like mkdir.
> 
> Thanks,
> Klaus

Re: svnsync checksum error

[Daniel Shahaf]

OSG wrote on Tue, Nov 09, 2010 at 20:58:53 -0600:
> On 11/09/2010 06:41 PM, Daniel Shahaf wrote:
> > Edward Ned Harvey wrote on Sat, Nov 06, 2010 at 20:29:18 -0400:
> >>> From: opensrcguru [mailto:opensrcg...@gmail.com]
> >>>
> >>> Today, the sync process started failing on 1 repo (all others were
> >>> unaffected) on both r/o copies at the exact same time/same revision
> >>> with errors similar to the following...
> >>>
> >>> Transmitting file data .svnsync: Base checksum mismatch on
> >>> '/path/to/file/foo/bar':
> >>>expected:  2f2e025c4c4855e7466799a877b3e23d
> >>>  actual:  272214b9518d352e16e7eeceeb22f573
> >>
> > 
> > Can you compare the contents of /path/to/file/foo/bar between the master
> > and mirror, as of the last revision successfully synced to the mirror?
> Yes, I had done that and yes, the last sync'd revs were in tact and accurate.
> 

So they are textually identical?  Can you compare their checksums to the
two checksums in the error message?

> > If you create a fresh mirror and svnsync it, from r0 to that revision,
> > does the file /path/to/file/foo/bar in the fresh mirror differ from the
> > one in the master?
> No, a resync from r0 to current does not result in any differences.
> 

Meaning, a fresh resync is successful and doesn't cause any error messages?

Or meaning, it results in the same error messages as before?

Re: svnsync checksum error

['Daniel Shahaf']

Edward Ned Harvey wrote on Wed, Nov 10, 2010 at 00:28:48 -0500:
> > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> > 
> > Can you compare the contents of /path/to/file/foo/bar between the master
> > and mirror, as of the last revision successfully synced to the mirror?
> 
> The latest rev which synced without reporting any error was 5045.  It was
> trying to go from 5045 to 5046 when it triggered the checksum failure.
> 
> I checked the history of the file in question, and it was changed in ~200
> different revs.  But the revs of interest are:  in 4390, it synced to the
> slave without reporting any error, however, from 4390 onward, if I checkout
> from the slave and master, the two files differ.  And the next rev where
> this file was changed was 5046, which is when svnsync notices the checksum
> mismatch, and dies.
> 

Okay.

> It would seem, all of this behavior could be explained by a simple
> undetected hardware error.  During sync of 4390, the slave wrote some bits
> to disk, which got written wrongly.  It is known that disks will do this
> rarely.  This is one of the huge arguments in favor of ZFS and BTRFS and
> filesystem checksumming in general.  Such filesystems detect and correct
> data corruption which would have otherwise passed silently...  Which seems
> to be what happened in my case.
> 

Yes, the question is whether this thread is just a bunch of hardware
errors, or something deeper.

> All servers and clients are running 1.6.12.  However, at the time when 4390
> was committed...  The master was 1.6.12, but the slave was probably 1.5.7
> 
> 
> > If you create a fresh mirror and svnsync it, from r0 to that revision,
> > does the
> > file /path/to/file/foo/bar in the fresh mirror differ from the one in the
> > master?
> 
> No problems.  Although ... I didn't let it sync from rev 0.  (That would be
> impossibly time consuming...  weeks)  I did as mentioned before.
> Transferred a backup of the master to the slave, and used it as the "seed"
> for the sync, so I only needed to sync the last 100 revs or something like
> that...
> 

That would mean that the "last changed revision" --- r4390 --- is
contained in the seed and wasn't re-svnsync'd.  If we suspect that
svnsync committed a bogus r4390 to the slave, we'd better start with
a slave that /doesn't/ already have a knowingly-good r4390...

Of course, you can take that backup and use it to produce a repository
whose youngest revision is earlier than r4390.

Re: SVN Usage - working on both tag and trunk

[Daniel Becroft]

On Thu, Nov 11, 2010 at 4:26 AM, Jonathan dos Santos <
jonat...@prioriti.com.br> wrote:

>  Hello, first of all if I’m infringing any rule on the mailing list I’m
> really sorry. I’ve tryied searching but couldn’t find a good phrase to
> describe my problem.
>
>
>
> I’m pretty new to svn and version control so this question may be very
> elementary:
>
>
>
> In our company we use SVN to manage the source code of our Delphi
> applications, generally we use trunks tomake changes to the source code and
> we only generate tags when we need to deploy the implemented features, still
> bugs happen and since the software is used in critical processes (at least
> for our clients they are critical…) , we need to fix bugs and deploy the
> corrections quickly sometimes,
>
> generally we need to develop both in the trunk and the tag and sometimes
> that’s really frustrating – mainly because some processes are huge and after
> each minimal change we need to test it over and over in a dozen ways, I try
> my best to use patches or to convince the deployer to make a new tag. Still
> It happens more often the I wish it too, is there a way to prevent this
> through SVN or its more of a company problem unrelated to svn usage? Or
> maybe its just me ?
>
>
>
> Thanks for your help in advance
>

It sounds like a little of both.

1) Tags are usually read-only, so you could prevent modification via
pre-commit hooks or path-based authorization of some sort.

2) The 'standard' process for using trunk/branches/tags structure is:
develop on trunk, merge to a release branch, and system-test there. Once
ready, tag the branch. If a change needs to be made (ie urgent fix), then
make it on trunk, merge to the release branch, and re-tag.

Cheers,
Daniel B.

Re: svnserve : anonymous access not working

[Daniel Shahaf]

I agree that anon-access=read should work.  From looking at the code,
I'm not sure whether the SASL glue logic signals "I couldn't auth this
user", or just returns an error.  In the meantime, as a workaround, does
adding ANONYMOUS to the mech_list achieve the desired behaviour?

Gingko wrote on Wed, Nov 10, 2010 at 21:04:50 +0100:
> - Original Message - From: "Gingko" 
> 
> To: "Subversion User List" 
> Sent: Wednesday, November 10, 2010 5:39 PM
> Subject: svnserve : anonymous access not working
>
>
>> Hello,
>>
>> I have a problem with svnserve :
>>
>> I want to configure it for allowing anonymous users to read it, but this
>> don't work :
>> if I checkout (using TortoiseSVN), I am always asked to supply my  
>> password.
>>
>> If I do it, the checkout works fine.
>>
>> Otherwise I cannot checkout.
>>
>> And if I click "OK" (in the TortoiseSVN authentication dialog) without
>> giving any authentication (leaving all fields empty), I get the following
>> message :
>>
>>   SASL(-1): generic failure: Unable to find a callback: 2
>>
>> svnserve (from Subversion 1.6.12) runs on a Linux server with Debian lenny
>> 5.0 (64 bit edition).
>>
>> The "svnserve.conf" file for that repository contains the following :
>> 
>> [general]
>> anon-access = read
>> auth-access = write
>> realm = Référentiel Pouchin TV Mod
>>
>> [sasl]
>> use-sasl = true
>> min-encryption = 128
>> max-encryption = 256
>> 
>>
>> For SASL, I have also a "svn.conf" file in the "/etc/" directory,  
>> containing the
>> following :
>> 
>> pwcheck_method: auxprop
>> auxprop_plugin: sasldb
>> sasldb_path: /var/lib/svn/sasldb
>> mech_list: DIGEST-MD5
>> 
>>
>> Note that there is also an Apache access, running concurrently, which  
>> works
>> fine for anonymous reading. But I also want this anonymous access on
>> svnserve.
>>
>> svnserve is configured for logging all accesses, but the log doesn't  
>> record
>> anything during theses failing anonymous accesses.
>>
>> svnserve is launched through the "inetd.conf" file, and the corresponding
>> line is :
>>
>>svn stream  tcp nowait www-data
>> /usr/bin/svnserve  svnserve -i --log-file /var/log/svnserve.log -r
>> /var/lib/svn
>>
>> I don't understand why it doesn't work.
>>
>> Isn't it enough to set "anon-access = read" for allowing anonymous reading
>> access ?
>> What am I doing wrong ?
>>
>> Best regards,
>>
>> Gingko
>
>
>
> Hello again,
>
> While searching on the web, I found a one year old message thread from 
> this very same list describing, on its very last message, a case that 
> looks like my one.
>
> Unfortunately, the question has never been answered (maybe because not  
> clearly asked, or maybe because the message was sent just before 
> Subversion moved from Tigris to Apache?).
>
> http://svn.haxx.se/users/archive-2009-11/0313.shtml
>
> Please, could you confirm that it is really possible to use svnserve with 
> SASL (for writing), AND allowing anonymous read access at once?
>
> Gingko
>
>
>

Re: Sparse checkouts automation

[Daniel Becroft]

On Thu, Nov 11, 2010 at 9:10 AM, San Martino  wrote:

> Hello,
>
> Suppose you have a layout like this:
> /trunk
>/dir1
>   /dir1_1
>  file1.txt
>  file2.txt
>   /dir1_2
>
> Is there a way with one command to sparse-checkout al the elements
> of the path to file1.txt (included) but no more than those elements ?
>
> That is, the local working copy should look like this after one command:
> /trunk
>   /dir1
>  /dir1_1
> file1.txt
>
> Note that file2.txt and dir1_2 won't appear.
>

With one command, no. But you can do the following:

svn checkout --depth=empty svn://host/repository/trunk trunk
cd trunk
svn update --depth=empty dir1
cd dir1
svn update --depth=empty dir1_1
cd dir1_1
svn update file1.txt

There's probably a quicker method of doing it, but you'll still need
multiple commands.

Cheers,
Daniel B.

Re: svnsync checksum error

[Daniel Shahaf]

Stefan Sperling wrote on Thu, Nov 11, 2010 at 13:29:14 +0100:
> I'm not sure what svnadmin verify is doing wrong in your case.
> But I know that there are corruptions it doesn't detect, and we're
> planning to improve this situation:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3706

What's the recommendation in the meantime?  To use 'dump'?  To use
'dump|load'?  To use svnsync (...)?  To manually walk the entire
history and recompute all checksums?

Re: History of a fixed path across all objects

[Daniel Shahaf]

Klaus Ganser wrote on Thu, Nov 11, 2010 at 13:09:51 -0800:
> It would be nice for this feature to see the light of day.

For this, we'll need a design that makes it possible to answer the
query efficiently.

Feel free to submit one; our documentation is in the text files
subversion/libsvn_fs_base/notes/** and subversion/libsvn_fs_fs/structure
(I'm not sure that's exhaustive).

Daniel
(also, we were contributed an SQL backend a while ago, but nothing
happened with that and I don't know how well it'll help your use case)

> -Klaus

Re: svnserve.exe (Win32) using 2GB of memory and then crashing?

[Daniel Shahaf]

Fixed in 1.6.14, which will be released in a week.  The CHANGES file in
trunk already contains an appropriate entry :-)

http://svn.apache.org/repos/asf/subversion/trunk/CHANGES

Keith Moore wrote on Fri, Nov 12, 2010 at 15:30:35 +1100:
> 
> > -Original Message-
> > From: Chris Tashjian [mailto:ct...@thepond.com]
> > Sent: Friday, 5 November 2010 11:20
> > To: Daniel Shahaf
> > Cc: users@subversion.apache.org
> > Subject: Re: svnserve.exe (Win32) using 2GB of memory and then crashing?
> > 
> > 
> > > Wrong format file.  Please look at the file 'db/format', not the file
> > 'format'.  Thanks.
> > 
> > 4
> > layout linear
> 
> Did you get a solution to this problem, or are you still looking into it?
> 
> I have a server running svnserve.exe as a windows service and every couple of 
> weeks in runs out of resources.  Not being a server engineer I can't even 
> figure out what resource because I can't log onto the server once it has ran 
> out of resources.
> 
> Please post any solution you come up with.
> 
> Thanks
> Keith.
> #
> Attention:
> The information contained in this message and or attachments is intended
> only for the person or entity to which it is addressed and may contain
> confidential and/or privileged material. Any review, retransmission,
> dissemination or other use of, or taking of any action in reliance upon,
> this information by persons or entities other than the intended recipient
> is prohibited. If you received this in error, please contact the sender and
> delete the material from any system and destroy any copies.
> #

Re: svnserve.exe (Win32) using 2GB of memory and then crashing?

[Daniel Shahaf]

Daniel Shahaf wrote on Fri, Nov 12, 2010 at 10:30:46 +0200:
> Fixed in 1.6.14, which will be released in a week.  The CHANGES file in
> trunk already contains an appropriate entry :-)

Having a CHANGES entry implies that the fix has been backported to the
1.6.x branch already; IOW, you could install ^/subversion/branches/1@head
today instead of waiting for the 1.6.14 release.

Re: Subversion vs multicore processors

[Daniel Shahaf]

Edward Ned Harvey wrote on Sat, Nov 13, 2010 at 00:23:54 -0500:
> ./configure --prefix=$INSTALLDIR --with-ssl && \
> make && \
> make install && \
> echo "" && \
> echo "installed ok:  ${INSTALLDIR}/bin/svn"

set -e
./configure
make
make install
set +e

More readable?

Merging case-only renames to branch

[Daniel Becroft]

Hi,

We've recently had to rename a couple of files on trunk by case only (e.g.
FOO.C to foo.c), which we did via a URL-only rename. This worked perfectly.

We then encountered a strange error when attempting to merge this revision
across to our release branch. Because the revision contains both an ADD and
a DELETE for (essentially) the same file, we got an "Error bumping revisions
post-commit)" message. I've reproduced the error with a sandpit environment
using 1.6.13 (below).

--- Merging r4 through r5 into '.':
AA\alpha.txt
DA\ALPHA.TXT
Sending.
Deleting   A\ALPHA.TXT
Adding A\alpha.txt
svn: Commit succeeded, but other errors follow:
svn: Error bumping revisions post-commit (details follow):
svn: In directory 'D:\temp\svn_sandpit\workingcopy\branchA\A'
svn: Error processing command 'committed' in
'D:\temp\svn_sandpit\workingcopy\branchA\A'
svn: Error getting 'affected time' for
'D:\temp\svn_sandpit\workingcopy\branchA\A\.svn\text-base\alpha.txt.svn-base'
svn: Can't stat
'D:\temp\svn_sandpit\workingcopy\branchA\A\.svn\text-base\alpha.txt.svn-base':
The system cannot find the file specified.

Interestingly, if I change my reproduction script to rename from alpha.txt
to ALPHA.txt, the commit works correctly.

--- Merging r4 through r5 into '.':
AA\ALPHA.TXT
DA\alpha.txt
Sending.
Adding A\ALPHA.TXT
Deleting   A\alpha.txt
Committed revision 6.

My question(s) are:
1) How should a merge of a case-only rename be managed? Is it a matter of
merging up to rX, manually renaming in the branch, recording the merge for
rX, then merging the rest? Or is there a cleaner method?
2) Should the order of the rename actually matter? In the above example(s)
renaming of UPPER to lower caused the error, but renaming from lower to
UPPER did not.

The same script (running using an old build of 1.7) gives the following
message:

--- Merging r4 through r5 into '.':
AA\alpha.txt
DA\ALPHA.TXT
--- Recording mergeinfo for merge of r4 through r5 into '.':
 U   .
Sending.
Deleting   A\ALPHA.TXT
Adding A\alpha.txt
svn: Commit succeeded, but other errors follow:
svn: Error bumping revisions post-commit (details follow):
svn: Error processing post-commit work for
'D:\temp\svn_sandpit\workingcopy\branchA\A\alpha.txt'
svn: File 'D:\temp\svn_sandpit\workingcopy\branchA\A\alpha.txt' has no text
base

Different wording, but same problem.
---
Daniel Becroft

Re: svnserve : anonymous access not working on SASL

[Daniel Shahaf]

Gingko wrote on Sat, Nov 13, 2010 at 21:18:14 +0100:
> - Original Message - From: "Daniel Shahaf" 
> 
> To: "Gingko" 
> Cc: "Subversion User List" 
> Sent: Wednesday, November 10, 2010 10:45 PM
> Subject: Re: svnserve : anonymous access not working
>
>
>> I agree that anon-access=read should work.  From looking at the code,
>> I'm not sure whether the SASL glue logic signals "I couldn't auth this
>> user", or just returns an error.  In the meantime, as a workaround, does
>> adding ANONYMOUS to the mech_list achieve the desired behaviour?
>
> Hello,
>
> Anything new on this subject ?
> Is there another workaround that you could suggest ?
>

Unfortunately no.  I don't have an SASL setup myself, my advise was
based mostly on reading the code.

> Maybe I should file a bug report about it on your issue tracker  
> (http://subversion.apache.org/issue-tracker.html) ?
>

I hope someone more familiar with SASL could comment.

But if after scanning the usual places (book, archives, SASL docs) you
haven't managed to get SASL + anonymous access to interact properly, I'm
fine with recording an issue for this.  (It might turn out to be
a documentation issue, but that's still a bug.)

Please link to this thread from the issue.

> Gingko 
>

Re: Merging case-only renames to branch

[Daniel Shahaf]

Can you try with a newer 1.7 build?

Re FOO->foo or foo->FOO, I suspect it's because we iterate some hash
table's keys (so the order of iteration is unpredictable).

Daniel
(it's actually a thread for dev@)


Daniel Becroft wrote on Mon, Nov 15, 2010 at 10:12:39 +1000:
> Hi,
> 
> We've recently had to rename a couple of files on trunk by case only (e.g.
> FOO.C to foo.c), which we did via a URL-only rename. This worked perfectly.
> 
> We then encountered a strange error when attempting to merge this revision
> across to our release branch. Because the revision contains both an ADD and
> a DELETE for (essentially) the same file, we got an "Error bumping revisions
> post-commit)" message. I've reproduced the error with a sandpit environment
> using 1.6.13 (below).
> 
> --- Merging r4 through r5 into '.':
> AA\alpha.txt
> DA\ALPHA.TXT
> Sending.
> Deleting   A\ALPHA.TXT
> Adding A\alpha.txt
> svn: Commit succeeded, but other errors follow:
> svn: Error bumping revisions post-commit (details follow):
> svn: In directory 'D:\temp\svn_sandpit\workingcopy\branchA\A'
> svn: Error processing command 'committed' in
> 'D:\temp\svn_sandpit\workingcopy\branchA\A'
> svn: Error getting 'affected time' for
> 'D:\temp\svn_sandpit\workingcopy\branchA\A\.svn\text-base\alpha.txt.svn-base'
> svn: Can't stat
> 'D:\temp\svn_sandpit\workingcopy\branchA\A\.svn\text-base\alpha.txt.svn-base':
> The system cannot find the file specified.
> 
> Interestingly, if I change my reproduction script to rename from alpha.txt
> to ALPHA.txt, the commit works correctly.
> 
> --- Merging r4 through r5 into '.':
> AA\ALPHA.TXT
> DA\alpha.txt
> Sending.
> Adding A\ALPHA.TXT
> Deleting   A\alpha.txt
> Committed revision 6.
> 
> My question(s) are:
> 1) How should a merge of a case-only rename be managed? Is it a matter of
> merging up to rX, manually renaming in the branch, recording the merge for
> rX, then merging the rest? Or is there a cleaner method?
> 2) Should the order of the rename actually matter? In the above example(s)
> renaming of UPPER to lower caused the error, but renaming from lower to
> UPPER did not.
> 
> The same script (running using an old build of 1.7) gives the following
> message:
> 
> --- Merging r4 through r5 into '.':
> AA\alpha.txt
> DA\ALPHA.TXT
> --- Recording mergeinfo for merge of r4 through r5 into '.':
>  U   .
> Sending.
> Deleting   A\ALPHA.TXT
> Adding A\alpha.txt
> svn: Commit succeeded, but other errors follow:
> svn: Error bumping revisions post-commit (details follow):
> svn: Error processing post-commit work for
> 'D:\temp\svn_sandpit\workingcopy\branchA\A\alpha.txt'
> svn: File 'D:\temp\svn_sandpit\workingcopy\branchA\A\alpha.txt' has no text
> base
> 
> Different wording, but same problem.
> ---
> Daniel Becroft

Re: Problem with diff after merging

[Daniel Shahaf]

Doesn't 'svn diff' say something to the effect of "A file with 
name was added"?


There is also:

% $svn h diff | grep add
  --show-copies-as-adds [--sca] : don't diff copied or moved files with their 
source

... but I think it's only in 1.7.

Jahn Otto Andersen wrote on Mon, Nov 15, 2010 at 10:20:00 +0100:
> I am using a code review tool called ReviewBoard to do code reviews. This
> tool uses svn diff to report the changes between BASE and work area.
> 
>  
> 
> I'm having problems when working in a branch and then merging into trunk.
> This problem seems to be caused by the diff generated by svn diff.
> 
>  
> 
> What I do: 
> 
> 1. Create a new branch based on trunk using TortoiseSVN's "branch" function
> 2. Commit several changes into the branch, including creating new files 
> 3. Reintegrate branch into trunk using TortoiseSVN's "reintegrate branch"
> function.
> 4. Generate the diff using svn diff and use this for the code review 
> 
> The problem is:
> 
> The diff that is created by svn diff does not contain the new file. The diff
> file contains the following lines (given that the new file is named
> NewFile.cs): 
> 
>  
> 
>  
> Property changes on: NewFile.cs 
> ___ 
> Modified: svn:mergeinfo 
>Merged /blabla/branches/mybranch/NewFile.cs:r11226-11336 
> -
> 
>  
> 
> It seems like the diff contains information about the fact that the new file
> is being merged into trunk from the branch, but it doesn't contain the
> actual lines in the new file. As a result, the review request in ReviewBoard
> doesn't contain NewFile.cs at all. 
> 
> Is there any way I can make svn diff include the new lines in the new file?
> 
>  
> 

Re: SVN group authentication to AD

[Daniel Shahaf]

Might be better to ask this on the *...@httpd.apache.org lists?

Dale Bohl wrote on Mon, Nov 15, 2010 at 07:39:59 -0600:
> Hello,
> 
>  
> 
> I've been banging my head on this one for 2 days now.
> 
> I've googled this issue but it appears not many admins are using this
> and/or
> 
> it could possibly be a bug in the apache module.
> 
>  
> 
> Config
> 
> --
> 
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
> 
> Server version: Apache/2.2.3
> 
> svn, version 1.6.12 (r955767)
> 
> Windows 2008 R2
> 
>  
> 
>It appears that we cannot use Active Directory Permissions Groups
> 
> with the s-svn server for Subversion repository authentication and
> authorization
> 
> but yet AD Role groups work just fine.
> 
>  
> 
> subversion.conf config for "puppet" repository
> 
> 
> 
> #puppet repo===
> 
> 
> 
>DAV svn
> 
>SVNPath /repos/puppet
> 
>AuthPAM_Enabled on
> 
>AuthType Basic
> 
>AuthName "Subversion Authentication to AD"
> 
>  
> 
># Limit R/W access to certain role groups
> 
>
> 
> #  Require group SVN-Puppet-ReadWrite-P
> 
>   Require group IT-InfrastructureTeam-SystemAdministrator-R
> 
>
> 
>  
> 
># Limit R/O access to certain role group
> 
>
> 
> #  Require group SVN-Puppet-ReadWrite-P
> 
>   Require group IT-InfrastructureTeam-SystemAdministrator-R
> 
>
> 
> 
> 
>  
> 
> The interesting thing is that AD Role Groups appear to work fine within
> 
> the Location directive config above which shows the role group for which
> 
> I'm a member.
> 
>  
> 
> If the above config is changed to use the Permissions group shown
> commented
> 
> out, authentication doesn't work and when that happens I'm seeing the
> following
> 
> error in ssl_error_log.
> 
>  
> 
> [Fri Nov 12 13:10:18 2010] [error] [client 172.16.4.7] GROUP: dpb not in
> required group(s).
> 
>  
> 
> So, even though the following User > Role > Permissions > Resource
> association
> 
> exists, the group with '-P' in it above won't allow dpb to authenticate
> for repo access.
> 
>  
> 
> dpb is a member of IT-InfrastructureTeam-SystemAdministrator-R and
> 
> IT-InfrastructureTeam-SystemAdministrator-R is a member of
> SVN-Puppet-ReadWrite-P AD
> 
> group
> 
>  
> 
> Any help would be greatly appreciated.
> 
>  
> 
> 
> 
> Dale Bohl
> Sr. Systems Administrator
> Mason Companies, Inc.
> db...@masoncompaniesinc.com  
> (715)-720-4382
> 
>  
> 

Re: Merging case-only renames to branch

[Daniel Becroft]

 On Mon, Nov 15, 2010 at 11:44 PM, David Weintraub wrote:

> On Sun, Nov 14, 2010 at 7:12 PM, Daniel Becroft 
> wrote:
> > Hi,
> >
> > We've recently had to rename a couple of files on trunk by case only
> (e.g.
> > FOO.C to foo.c), which we did via a URL-only rename. This worked
> perfectly.
> >
> > We then encountered a strange error when attempting to merge this
> revision
> > across to our release branch. Because the revision contains both an ADD
> and
> > a DELETE for (essentially) the same file, we got an "Error bumping
> revisions
> > post-commit)" message. I've reproduced the error with a sandpit
> environment
> > using 1.6.13 (below).
>
> Okay, you're using Windows. On Windows, Foo and foo are the same file,
> but on Unix, they're two different files. Subversion is suppose to be
> case sensitive, so Foo and foo are two different files in Subversion
> whether or not the server or client are on Windows systems or Unix
> systems.
>

I realize that, hence why we did our initial renames via URLs, rather than
in a working copy. My question was not so much "Why did I get this
message?", but how should such a change be merged between trunk and branch.
Any merge requires a working copy.

I suspect that the correct method is:
 - Merge everything up to and including) rX-1, and commit.
 - Rename file manually over URL
 - Record-only merge of rX
 - Merge everything from (and including) rX+1 to HEAD, and commit.


> Do you have any post-commit hooks? If you are, are the messages being
> generated by Subversion or the post commit hooks?
>

The messages are being generated by the client (there were no post-commit
hooks in my sample repository).

Cheers,
Daniel B.

URL-only renames adds svn:mergeinfo property

[Daniel Becroft]

Hi,

I've just found (another) issue with using URL-only renames. If one of the
parent directories has svn:mergeinfo recorded on it, then renaming a file
via a URL results in the new file containing a full copy of what was on the
trunk (but cut down to the individual file).

Please see the following output from my test script (using SVN 1.6.13):

>svn merge file:///D:/temp/svn_sandpit/repository/trunk .
--- Merging r4 through r5 into '.':
UA\alpha.txt

>svn commit . --message "Merge r5 from trunk to branch."
Sending.
SendingA\alpha.txt
Transmitting file data .
Committed revision 6.

>svn propget svn:mergeinfo
file:///D:/temp/svn_sandpit/repository/branches/branchA
/trunk:4-5

>svn propget svn:mergeinfo
file:///D:/temp/svn_sandpit/repository/branches/branchA/A/alpha.txt

>svn rename
file:///D:/temp/svn_sandpit/repository/branches/branchA/A/alpha.txt
file:///D:/temp/svn_sandpit/repository/branches/branchA/A/beta.txt --message
"Rename alpha.txt to beta.txt on branchA."
Committed revision 7.

>svn propget svn:mergeinfo
file:///D:/temp/svn_sandpit/repository/branches/branchA/A/beta.txt
/trunk/A/alpha.txt:4-5

Notice that the 'svn propget' on alpha.txt indicates that there is no
svn:mergeinfo property available, but it gets added to beta.txt during the
rename.

Is this intended behavior?


Daniel Becroft

Re: Completely overwrite a file.

[Daniel Shahaf]

Stefan Sperling wrote on Wed, Nov 17, 2010 at 14:09:47 +0100:
> Note that you could also use the --accept="theirs-full" option to skip the
> interactive prompt.
> 

In trunk, '--accept=tf' (using the shorthands from the interactive
resolver) also works.  I've nominated the shorter spelling for 1.6.14.

Thanks for the reminder.

Re: Prevent mod_dav_svn REPORT log failure if files under $REPOS/db/revprops/ are not in UTF-8 encoding

[Daniel Shahaf]

Stefan Sperling wrote on Wed, Nov 17, 2010 at 18:13:44 +0100:
> On Wed, Nov 17, 2010 at 03:06:19PM +, LiuYan 刘研 wrote:
> > I mean, if the revprops files are not in UTF-8 encoding, don't return 
> > REPORT 

Small correction: it's meaningless to talk about the encoding of the
revprop files; it's only meaningful to talk about the encoding of the
value of a given property.

(At the revprop files level, the values are binary, and the rest of the
data in those files is always ASCII.)

Re: Prevent mod_dav_svn REPORT log failure if files under $REPOS/db/revprops/ are not in UTF-8 encoding

[Daniel Shahaf]

LiuYan 刘研 wrote on Thu, Nov 18, 2010 at 02:53:37 +:
> Daniel Shahaf  daniel.shahaf.name> writes:
> 
> > 
> > Stefan Sperling wrote on Wed, Nov 17, 2010 at 18:13:44 +0100:
> > > On Wed, Nov 17, 2010 at 03:06:19PM +, LiuYan 刘研 wrote:
> > > > I mean, if the revprops files are not in UTF-8 encoding, don't return 
> REPORT 
> > 
> > Small correction: it's meaningless to talk about the encoding of the
> > revprop files; it's only meaningful to talk about the encoding of the
> > value of a given property.
> > 
> > (At the revprop files level, the values are binary, and the rest of the
> > data in those files is always ASCII.)
> > 
> > 
> 
> You're right Daniel, but in such situation, these revprop files can be 
> treated 
> as readable text files:

This is simply not true: if you apply 'iconv -f latin1 -t utf-8' to
a revprop file, you will CORRUPT that revprop file.

Re: URL-only renames adds svn:mergeinfo property

[Daniel Becroft]

On Tue, Nov 16, 2010 at 3:54 PM, Daniel Becroft wrote:

> Hi,
>
> I've just found (another) issue with using URL-only renames. If one of the
> parent directories has svn:mergeinfo recorded on it, then renaming a file
> via a URL results in the new file containing a full copy of what was on the
> trunk (but cut down to the individual file).
>
> Please see the following output from my test script (using SVN 1.6.13):
>
> >svn merge file:///D:/temp/svn_sandpit/repository/trunk .
> --- Merging r4 through r5 into '.':
> UA\alpha.txt
>
> >svn commit . --message "Merge r5 from trunk to branch."
> Sending.
> SendingA\alpha.txt
> Transmitting file data .
> Committed revision 6.
>
> >svn propget svn:mergeinfo
> file:///D:/temp/svn_sandpit/repository/branches/branchA
> /trunk:4-5
>
> >svn propget svn:mergeinfo
> file:///D:/temp/svn_sandpit/repository/branches/branchA/A/alpha.txt
>
> >svn rename
> file:///D:/temp/svn_sandpit/repository/branches/branchA/A/alpha.txt
> file:///D:/temp/svn_sandpit/repository/branches/branchA/A/beta.txt --message
> "Rename alpha.txt to beta.txt on branchA."
> Committed revision 7.
>
> >svn propget svn:mergeinfo
> file:///D:/temp/svn_sandpit/repository/branches/branchA/A/beta.txt
> /trunk/A/alpha.txt:4-5
>
> Notice that the 'svn propget' on alpha.txt indicates that there is no
> svn:mergeinfo property available, but it gets added to beta.txt during the
> rename.
>
> Is this intended behavior?
>

Is anyone able to confirm if this is intended behavior? After further
testing, I get the same results if I run an 'svn copy' via URLs. However, I
do not get the svn:mergeinfo property added if I 'svn rename' or 'svn copy'
in my working copy.

Cheers,
Daniel B.

Re: Prevent mod_dav_svn REPORT log failure if files under?$REPOS/db/revprops/ are not in UTF-8 encoding

[Daniel Shahaf]

DON'T DO IT THIS WAY.  Follow Stefan's advice upthread.

Re: Using a changelist with the revet command

[Daniel Shahaf]

I think it's intentional.

If we change the first command to have the semantics of the second
command, wouldn't it mean that the second command is equivalent to
'svn revert -R ./'?

If yes, we can't change it --- rather bad compatibility surprised for
everyone who's used to 'svn revert --cl foo -R ./'.

Giulio Troccoli wrote on Fri, Nov 19, 2010 at 11:33:54 +:
> Hi,
> 
> I have found an odd behaviour with the revert command. Maybe it's
> intended, but I don't find it very intuitive. I'm using SVN 1.6.9.
> 
> If I have a changelist and I want to revert all changes made in all
> files in the changelist I would use the following
> 
> svn revert --changelist 
> 
> That doesn't work. Not only I have to add the --depth option, but
> I also have to specify the PATH, so something like
> 
> svn revert --depth infinity --changelist  .
> 
> I don't think either are necessary though. The good thing about
> changelist is that with one easy command you can work on many files at
> ones, even if they are in different directories. With the above
> command, you still can, but from the deepest common directory of all
> the files in the changelist.
> 
> The changelist has the full path of every file, so I would have though
> that the first command I tried would be enough.
> 
> What do you think?
> 
> G
> 
> 
> Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V
> 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
> 
> 
> 
> 

Re: Version caching

[Daniel Shahaf]

Andy Levy wrote on Sun, Nov 21, 2010 at 11:14:43 -0500:
> Subversion only caches logs on the client.

Subversion itself doesn't.  I'm told TortoiseSVN does.

Re: Version caching

[Daniel Shahaf]

In Subversion 1.7, text-bases are stored in a SHA-1-keyed store (as
opposed to a pathname-based store in 1.6 and earlier), and the "old"
text-base aren't always removed as soon as there is no working copy file
corresponding to them.  (I tried committing a file in one wc and
updating that file in another wc; both wc's retained both text-bases.)

If the code is smart enough to not re-fetch something it has the text-base
for already, then your task boils down to changing Subversion's "when to
delete a text-base" policy (so as to make it keep more text-bases even
if they aren't referred to by any current file).


None of the above addresses log messages; however, for that you could
use other solutions.  One way is to enable commits mails and never
delete them.

Andrey Repin wrote on Sun, Nov 21, 2010 at 18:36:20 +0300:
> Greetings, Kevin Connor Arpe!
> 
> > I have a question about version caching.  I am using the latest
> > (stable) version on both Linux and WinSlows.
> 
> > As I understand Subversion, once a version is committed, basically it
> > can never changed.  A version is written in stone.
> 
> > If that is true, I was hoping Subversion could cache each versioned
> > copy that it downloads.  Currently, it seems running "log", "diff",
> > and "merge" takes quite some time (I am very far away from my
> > Subversion server at work... half the world.)
> 
> I strongly suggest you read http://svnbook.org/ before asking any questions
> about Subversion.
> 
> > Is there an add-on or option I can use to ask Subversion to never
> > throw away a version it sees?
> 
> For this your question, there's two answers, equally right.
> 1. It is a native property of a Subversion.
> 2. It's not possible, nor it is realistically applicable.
> 
> > That way if I run "log" or "merge" or "diff" against an older version I have
> > seen before... poof!  it is immediately available.
> 
> > I thought about mirroring the server in read-only mode, but I really
> > just want a local cache for versions that I might be looking at.
> 
> That's the same.

Re: file externals & URLs

[Daniel Shahaf]

Bastien Semene wrote on Tue, Nov 23, 2010 at 14:43:21 +0100:
> Is it still not possible to use file externals pointing on different  
> repositories ?

It is not possible (because the code used to implement in 1.5 and 1.6
them assumes that the target URL belongs to the same repository).

I don't recall if it's already fixed in trunk/1.7-to-be.

Re: file externals & URLs

[Daniel Shahaf]

Bastien Semene wrote on Tue, Nov 23, 2010 at 17:51:00 +0100:
> Ok, I just tested.
>
> There actually are 2 problems when I first tested the cross repositories  
> file external, the first message I had was :
> Repository UUID '55a45616-c74e-de11-b3fa-001e4f22e0e6' doesn't match  
> expected UUID '20aedb48-35eb-0310-b593-edfe3b26aac3'
>
> So I changed the UUID of my test repository (of course only for test  
> purposes and on a test repository),

Yes.

> re-co my wc and I had a new error :
> 'http://svn.cyanide-studio.com/test/external' is not the same repository  
> as 'http://svn.cyanide-studio.com/admin'
>
> It should be noted that I use TortoiseSVN, and maybe the second error is  
> from Tortoise that does some tests.
>

It sounds to me like an input-validation code in the Subversion
libraries themselves.

> I'm not in the Subversion code, but I think that the problem is not  
> related to URLs, but from UUIDs checks.

I think both of these (URLs and UUIDs) will need to be adjusted.

> Anyway I'm happy to know that this is a feature planned for 1.7 !
>

It's just another one of those features that the wc rewrite of 1.7 will
enable.  I don't recall if this is specifically planned for 1.7 or for
later --- but the dev@/issues@ archives have a better memory :).

Daniel

>
> Le 23/11/2010 17:17, Daniel Shahaf a écrit :
>> Bastien Semene wrote on Tue, Nov 23, 2010 at 14:43:21 +0100:
>>> Is it still not possible to use file externals pointing on different
>>> repositories ?
>> It is not possible (because the code used to implement in 1.5 and 1.6
>> them assumes that the target URL belongs to the same repository).
>>
>> I don't recall if it's already fixed in trunk/1.7-to-be.
>
> -- 
> Bastien Semene
> Administrateur Réseau&  Système
>
> Cyanide Studio - FRANCE
>

Re: file externals & URLs

[Daniel Shahaf]

Les Mikesell wrote on Tue, Nov 23, 2010 at 11:03:11 -0600:
> The current version uses the directory structure of your workspace to  
> hold the repository information, so it sort-of makes sense that you  
> can't mix files from different repositories in the same directory.

And why would this argument be less valid when subjected to s/files/dirs/ ?

There is no reason file externals shouldn't be able to be cross-repository.
(They were originally implemented in a way that doesn't allow that, but
that's another story.)

Re: URL-only renames adds svn:mergeinfo property

[Daniel Becroft]

On Wed, Nov 24, 2010 at 6:31 AM, Paul Burba  wrote:

> On Fri, Nov 19, 2010 at 12:25 PM, Stefan Sperling  wrote:
>
> Hi All,
>
> The short story, the following behaviors are intentional:
>
> A) WC-to-WC [copies | moves]: Destination only gets explicit mergeinfo
> if the source has it.
>
> B) URL-to-[WC | URL] [copies | moves]: Destination gets explicit
> mergeinfo if the source has it.  If the source doesn't have explicit
> mergeinfo, but inherits it, then that inherited mergeinfo is made
> explicit on the destination.
>
> The slightly longer story...
>
> As Stefan already mentioned, in 1.5.0-1.5.4 'A' behaved like 'B'.
> When we changed the WC-to-WC behavior in 1.5.5, we purposefully didn't
> change the URL-to-* behavior.  But honestly, this was probably as much
> out of caution as for any other reason, since there are use cases
> where 'B' helps you even when doing copies within the same branch (see
> my example that follows).
>
> If someone wants to make the argument on the dev list that 'A' should
> be the default behavior for all copies and moves, I for one am quite
> willing to listen and probably assist, and maybe do all the coding
> (which should be pretty minimal), but this isn't on my personal TODO
> list at the moment.
>

I'm not sure I have a firm argument either way (yet). It is a little strange
that the same command would produce different results when done WC-to-WC vs
URL-to-*.


>  > On Fri, Nov 19, 2010 at 12:38:57PM +0100, Johan Corveleyn wrote:
> >> I don't see why it matters that it's a "sub-branch". It's still a
> >> (grand-)child of mybranch, so can perfectly inherit that mergeinfo.
> >> AFAIU it only needs explicit mergeinfo if it starts to deviate from
> >> the mybranch root (e.g. if something is (sync-)merged directly to the
> >> sub-branch). Or am I missing something?
> >
> > Hmmm.. I don't see any reason either. Explicit mergeinfo could probably
> be
> > created later when the subtree actually becomes a merge target.
> > I guess the current logic in the code simply doesn't account for the case
> > where the copy destination is a child of the source? Not sure.
>



Now let's try the same merge, but targeting psi-WC.  We know from the
> preceding diagram that psi-WC's merge history should be semantically
> equivalent to psi-URL's and we *should* get a no-op, but instead...
>
>  >svn merge ^/trunk/D/H/psi branch\D\H\psi-WC -c6
>  Conflict discovered in 'branch/D/H/psi-WC'.
>  Select: (p) postpone, (df) diff-full, (e) edit,
>  (mc) mine-conflict, (tc) theirs-conflict,
>  (s) show all options: p
>  --- Merging r6 into 'branch\D\H\psi-WC':
>  Cbranch\D\H\psi-WC
>  Summary of conflicts:
>Text conflicts: 1
>

But merging the parent directories is a no-op, because the explicit merge
info on /branch stops r6 from being merged again.


> Why did this happen?  Because psi-WC's actual merge history (i.e. its
> natural history and explicit/implicit mergeinfo) doesn't include
> '/trunk/D/H/psi:6'.
>
> Now you may be thinking, "but doesn't it inherit that history from the
> root of branch?".  Unfortunately it doesn't, it does inherit mergeinfo
> from branch, but it inherits '/trunk/D/H/psi-WC:6', which is obviously
> not what we are merging and has the added distinction of not even
> existing in the repository**
>
> This is because mergeinfo inheritance is a simple path-wise
> calculation: A path without mergeinfo inherits the mergeinfo of its
> nearest parent with explicit mergeinfo, with all the merge source
> paths adjusted by the path difference between the path and its parent.
>


>  Yes, I'd love to come up with a more concise way to explain that!
>

The mergeinfo (from the parent) is /trunk:6, which means that the changes
made to /trunk in r6 have already been merged into a parent. I guess it's
naive for SVN to work out that I'm trying to merge a change to a sub-tree of
/trunk to a sub-tree of /branches, when the same revision has been merged
into a parent. I guess it's because SVN only looks at the merge target
itself when determine the eligible revisions, rather than walking the tree
until it hits a node with explicit mergeinfo.


> Anyhow, that is where not recording the source's inherited mergeinfo
> on the copy destination can bite us.  Is is a big problem?  Not sure,
> but the workaround to avoid it, using WC-to-WC copies, doesn't seem
> that draconian.  If you agree or not, I'm more than happy to kick
> around improvements on the dev list.
>

Agreed. The case that I had came about due to a case-only rename, and
because we run windows, we did it via a URL (rather than an intermediate
commit). We'll know for next time. :-)


> Thanks,
>
> Paul
>
> * I talk about copies here, but the same issues apply to moves.
>
> ** In 1.7 I made improvements so that such bogus inherited mergeinfo
> doesn't get recorded, see
> http://subversion.tigris.org/issues/show_bug.cgi?id=3669, but in
> 1.5-1.6 we have that added insult.
>

Re: svnsync_test.py fails: wrong version of SQLite library

[Daniel Shahaf]

Michael J. Bauer wrote on Tue, Nov 23, 2010 at 19:16:32 -0500:
> It looks like svnsync is picking up the wrong version of SQLite, despite  
> being compiled with the correct version.  This appears to happen only on  
> svnsync synchronize, but I've not exhaustively read through the logs.   

I'd be surprised if only svnsync (and MUCH more surprised if only
'svnsync sync') complain about wrong libraries.  The sqlite library
should be loaded by other cmdline utilities too...

Re: svnsync_test.py fails: wrong version of SQLite library

[Daniel Shahaf]

Couldn't hurt.  There's no need for the whole log though,
a representative sample should be enough...

Does it fail in the same way under 'make check' as under
'./svnsync_tests.py -v'?

(You can pass TESTS=subversion/tests/cmdline/svnsync_tests.py to 'make
check', by the way.)

Michael J. Bauer wrote on Wed, Nov 24, 2010 at 12:03:49 -0500:
> The only test that failed out of the 71 run by 'make check' was  
> svnsync_test.py.  The only things that appeared to fail within that test  
> were svnsync sync.  I can send the test log if you like.
>
> MJB
>
> On 11/24/2010 2:45 AM, Daniel Shahaf wrote:
>> Michael J. Bauer wrote on Tue, Nov 23, 2010 at 19:16:32 -0500:
>>> It looks like svnsync is picking up the wrong version of SQLite, despite
>>> being compiled with the correct version.  This appears to happen only on
>>> svnsync synchronize, but I've not exhaustively read through the logs.
>> I'd be surprised if only svnsync (and MUCH more surprised if only
>> 'svnsync sync') complain about wrong libraries.  The sqlite library
>> should be loaded by other cmdline utilities too...

Re: update locking unrelated parent directory

[Daniel Shahaf]

Ulrich Eckhardt wrote on Thu, Nov 25, 2010 at 09:38:25 +0100:
> Greetings!
> 
> I have a scenario where I can't update a working copy while an update on an 
> unrelated other working copy is in progress. The directory structure looks 
> like this:
> 
>   projects/
>   foo
>   foo-test-1 *
>   foo-test-2 *
>   lib_bar
> 
> Now, what makes this special is that in the repository, the marked foo-test 
> directories don't exist. These directories are just file-system copies of foo 
> which I made in order to do some tests while keeping the relation to lib_bar. 
> Theoretically, they should be independent roots of separate WCs, right? 
> However, while running update on either foo-test, it seems that the projects 

Have you tried both 'cd projects; svn up foo-test-1' and 'cd 
projects/foo-test-1; svn up'?

> root dir is locked, so I can't update the rest. However, I can update both 
> foo-test WCs in parallel.
> 
> Also, I wonder how the new 1.7 WC format will affect me here. As far as I 
> know, the metadata is stored in just the root folder of the working copy 
> there, which means that a file-system copy of a subdir is not a working copy 
> on its own, which means I can't achieve the above by using a file-system copy 
> but have to do a separate checkout of the subdirectory, rigth?
> 

Right.

> I also thought about using a local never-committed copy, which I would then 
> switch back to the original dir:
> 
>   svn cp foo foo-test
>   svn switch $(REPOS)/projects/foo foo-test
> 
> This should even allow me to update all my folders by issuing an update on 
> the 
> projects root folder. Well, at least it could, I don't know if it works, I'm 
> not even sure it should work.
> 

Or just use svn:externals to pull foo-test as foo-test-1.

> 
> Cheers!
> 
> Uli
> 
> -- 
> ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
> FAQ: http://subversion.apache.org/faq.html
> Docs: http://svnbook.red-bean.com/

Re: update locking unrelated parent directory

[Daniel Shahaf]

Ulrich Eckhardt wrote on Thu, Nov 25, 2010 at 14:34:19 +0100:
> On Thursday 25 November 2010, Daniel Shahaf wrote:
> > Ulrich Eckhardt wrote on Thu, Nov 25, 2010 at 09:38:25 +0100:
> > > Now, what makes this special is that in the repository, the marked
> > > foo-test directories don't exist. These directories are just file-system
> > > copies of foo which I made in order to do some tests while keeping the
> > > relation to lib_bar. Theoretically, they should be independent roots of
> > > separate WCs, right? However, while running update on either foo-test, it
> > > seems that the projects
> >
> > Have you tried both 'cd projects; svn up foo-test-1' and 'cd
> > projects/foo-test-1; svn up'?
> 
> According to the TSVN mailinglist, it always uses full paths:
> 
>svn update c:\projects\foo-test-1
> 

You could try the 'cd foo-test-1 && svn.exe up' syntax (using the
cmdline client).  I'm not sure whether or not that syntax will take
a lock on the parent dir.

> Uli
> 

Re: Unrecognized format for relative external URL './name'

[Daniel Shahaf]

We could implement support for ./foo relative externals, I suppose.  It
seems you have a use case for that.

Ulrich Eckhardt wrote on Thu, Nov 25, 2010 at 12:39:15 +0100:
> Hi!
> 
> I know that '../name' works as URL, why doesn't './name'? I just want an 
> alias 
> under a different name, that's all. Current workaround is that I 
> use '../parent/name' instead.
> 
> Uli
> 
> -- 
> ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
> FAQ: http://subversion.apache.org/faq.html
> Docs: http://svnbook.red-bean.com/
> 
> 
> **
> Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
> **
> Visit our website at 
> **
> Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
> bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
> Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
> sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
> weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
> E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
> Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht 
> verantwortlich.
> **
> 
>