Re: TortoiseSVN bug - assertion failure

[Stefan Sperling]

On Fri, Jun 13, 2014 at 05:00:30PM -0700, Ed wrote:
> In file
>  
> 'D:\Development\SVN\Releases\TortoiseSVN-1.8.7\ext\subversion\subversion\libsvn_wc\wc_db.c'
>  line 13676: assertion failed (svn_dirent_is_absolute(local_abspath))
> ---
> OK   
> ---
> 
> The circumstances involving the assertion were as follows:
> 1) In repo-browser, I created a folder directly under "trunk".
> 2) I attempted to check this folder out to a directory that already contained 
> actual versionable files (i.e., source files)*.
> When I attempted the checkout, I got the error.
> I may revert to an older version of TortoiseSVN, since I've never gotten that 
> error before, and it's preventing me from adding projects (unless I use 
> another technique).
> 
> [*This is how I add a project to source control. After checking out a new, 
> empty project, I use 
> TortoiseSvn (from the explorer menu) to add the revelevant files, then 
> perform a commit.]
> 
> I don't know whether I'm sending this post to the correct address, as the 
> instructions for bug reporting are very poorly written.
> 
> 
> 
> I don't know whether I'm sending this report to the correct place, as the 
> instructions for bug reporting are extremely poor.

Hi Ed,

please report this to the tortoisesvn project (http://tortoisesvn.net)
It looks like torotisesvn might be passing relative paths where
it should be passing absolute ones.

Subversion Exception

[Roy Umbach]

Subversion reported the following
(you can copy the content of this dialog
to the clipboard using Ctrl-C):

In file
 
'D:\Development\SVN\Releases\TortoiseSVN-1.8.7\ext\subversion\subversion\libsvn_wc\wc_db_update_move.c'
 line 1039: assertion failed (move_dst_revision ==
expected_move_dst_revision
 || status == svn_wc__db_status_not_present)

problem: svnsync to external ISCSI drive increases size of repos

[Korte, Michael Johannes]

Hello all,

I have the following problem and I don't know whether this is an error in 
subversion, whether I make some user error, or whether this normal behaviour.

I'm using subversion (Version 1.7.9) on a Ubuntu Linux machine (Ubuntu 12.04.4 
LTS (GNU/Linux 3.2.0-64-generic x86_64)).

For backup I use svnsync to create a mirror on an external ISCSI drive. The 
curious thing is now that for some mirror repositories the size is exact the 
same as for the original repositories. For some the size of the mirror 
repositories is little bigger and for some it is much bigger, for one double 
the size. When I check the size of the single revisions, most of them are 
identically but some differ very big between the original the revision and the 
revision in the mirror.
Originally I thought with the size of the backup/mirror, I can easily verify 
that the backup is fine/complete.

There are two other curious things:
When I sync back the mirror to the Linux system the size is reduced again and 
is exactly the size of the original repo.

Original the repos on the Linux system were created (by svnsync) from the 
backup on the ISCSI drive which was filled from repos on a  Windows system. By 
this svnsync (the sync from Windows to ISCSI as well as the sync from ISCSI to 
Linux)  the size of the repos did not change.

This means I watch the following behaviour:

Svnsync from Windows to Windows : no change of repository size
Svnsync from Windows to ISCSI drive : no change of repository size
Svnsync from ISCSI drive to Linux : normaly no change of repository size 
(expection if the ISCSI repository was originally synced from Linux, the during 
the ISCSI --> Linux sync the repository size is reduced to the original size on 
Linux))
Svnsync from Linux to Linux:  no change of the repository size
Svnsync from Linux to ISCSI drive : repository size is increased. For some 
repositories only little, for some very much (e.g. Double size)
Svnsync from Linux to ISCSI and back to Linux : First size is increased and 
then size is reduced for the same rate, this means after both syncs the size is 
again identical.

Is it normal that the repository size is changed during sync from Linux to 
external ISCSI drive? Why is the size changed very much (factor 1 :10) for 
single revisions. Do I make any error during svnsync, or is this the normal 
behaviour?

Does this mean if I want to use the backup from the ISCSI drive on my Linux 
system I must to a sync back and it is no good idea, to only a robocopy of the 
Repository content from the ISCSI drive to the Linux file system?

Thanks in advance.

Best regards
Michael Korte

Re: problem: svnsync to external ISCSI drive increases size of repos

[Andreas Stieger]

Hello,

> On 16 Jun 2014, at 12:50, "Korte, Michael Johannes"  
> wrote:
> 
>  
> Svnsync from Windows to Windows : no change of repository size
> Svnsync from Windows to ISCSI drive : no change of repository size
> Svnsync from ISCSI drive to Linux : normaly no change of repository size 
> (expection if the ISCSI repository was originally synced from Linux, the 
> during the ISCSI à Linux sync the repository size is reduced to the original 
> size on Linux))
> Svnsync from Linux to Linux:  no change of the repository size
> Svnsync from Linux to ISCSI drive : repository size is increased. For some 
> repositories only little, for some very much (e.g. Double size)
> Svnsync from Linux to ISCSI and back to Linux : First size is increased and 
> then size is reduced for the same rate, this means after both syncs the size 
> is again identical.

Check if rep-cache.db is created and filled? Check if representation sharing is 
enabled?

Does the same happen for svnadmin hotcopy?

>  
> Is it normal that the repository size is changed during sync from Linux to 
> external ISCSI drive?

Sometimes, e.g. when not using representation sharing.

> Why is the size changed very much (factor 1 :10) for single revisions. Do I 
> make any error during svnsync, or is this the normal behaviour?

Depends on usage, yes they can be different if the rep sharing database differs 
or is enabled differently.

Andreas

Re: problem: svnsync to external ISCSI drive increases size of repos

[Johan Corveleyn]

On Mon, Jun 16, 2014 at 1:50 PM, Korte, Michael Johannes
 wrote:
> Hello all,
>
>
>
> I have the following problem and I don’t know whether this is an error in
> subversion, whether I make some user error, or whether this normal
> behaviour.
>
>
>
> I’m using subversion (Version 1.7.9) on a Ubuntu Linux machine (Ubuntu
> 12.04.4 LTS (GNU/Linux 3.2.0-64-generic x86_64)).
>
>
>
> For backup I use svnsync to create a mirror on an external ISCSI drive. The
> curious thing is now that for some mirror repositories the size is exact the
> same as for the original repositories. For some the size of the mirror
> repositories is little bigger and for some it is much bigger, for one double
> the size. When I check the size of the single revisions, most of them are
> identically but some differ very big between the original the revision and
> the revision in the mirror.
>
> Originally I thought with the size of the backup/mirror, I can easily verify
> that the backup is fine/complete.
>
>
>
> There are two other curious things:
>
> When I sync back the mirror to the Linux system the size is reduced again
> and is exactly the size of the original repo.
>
>
>
> Original the repos on the Linux system were created (by svnsync) from the
> backup on the ISCSI drive which was filled from repos on a  Windows system.
> By this svnsync (the sync from Windows to ISCSI as well as the sync from
> ISCSI to Linux)  the size of the repos did not change.
>
>
>
> This means I watch the following behaviour:
>
>
>
> Svnsync from Windows to Windows : no change of repository size
>
> Svnsync from Windows to ISCSI drive : no change of repository size
>
> Svnsync from ISCSI drive to Linux : normaly no change of repository size
> (expection if the ISCSI repository was originally synced from Linux, the
> during the ISCSI à Linux sync the repository size is reduced to the original
> size on Linux))
>
> Svnsync from Linux to Linux:  no change of the repository size
>
> Svnsync from Linux to ISCSI drive : repository size is increased. For some
> repositories only little, for some very much (e.g. Double size)
>
> Svnsync from Linux to ISCSI and back to Linux : First size is increased and
> then size is reduced for the same rate, this means after both syncs the size
> is again identical.
>
>
>
> Is it normal that the repository size is changed during sync from Linux to
> external ISCSI drive? Why is the size changed very much (factor 1 :10) for
> single revisions. Do I make any error during svnsync, or is this the normal
> behaviour?
>
>
>
> Does this mean if I want to use the backup from the ISCSI drive on my Linux
> system I must to a sync back and it is no good idea, to only a robocopy of
> the Repository content from the ISCSI drive to the Linux file system?
>

First thing that comes to mind is that it might be related to the
new-in-1.6-feature of "representation sharing" [1]. If this feature is
enabled, a revision file that would normally contain a full
representation of a file, would now just contain a pointer to that
same representation in an older revision file.

I can imagine a couple of scenario's that could explain your situation:

- Perhaps the svnsync that blows up your repo is an older version (<
1.5), with no representation sharing? When svnsync'ing "back to Linux"
perhaps you're using again a more modern svnsync version, yielding
again a more compact repository (with representation sharing).

- Representation sharing might be disabled on the blown-up repository [2].

- Representation sharing might be broken in the blown-up repository.
For rep-sharing to work properly, the file rep-cache.db in /db should be accessible (writable) by the process that
performs the commits to the backend (usually the server process, or
the svnadmin / svnsync process if it's accessing the repository
backend directly with a file:/// url).

[1] http://subversion.apache.org/docs/release-notes/1.6.html#rep-sharing
[2] See the rep-sharing section in db/fsfs.conf in your repository directory.

-- 
Johan

New subversion bug?

[Croft, Joe]

Hi Yall,

I ran into the problem that when I do an svn copy command three times, it 
behaves differently each time. The command line is:

svn cp https://server.com/Projects/project_a/trunk 
https://server.com/Projects/project_a/tags/tag_a

The first time I run this I end up with what I expect, a directory with the url 
of

https://server.com/Projects/project_a/tags/tag_a

which contains the files and folders which are under 'trunk' of the original 
url.

The second time I run this I get an unexpected directory with the folder

https://server.com/Projects/project_a/tags/tag_a/trunk

which also contain all of the folders and files which are under the 'trunk' of 
the original url

On the third and subsequent executions of the same command, I get the error I 
expected on the second invocation except for the url that it complains about 
already existing. The error is

Svn: E160020: Path 'trunk' already exists.

I really  the error "Svn: E160020: Path 'tag_a' already exists" on the second 
invocation of the command.

I am running with svn server 1.6 on linux. The client can be windows or linux 
1.6 or 1.7. Adding a trailing slace ("/") to the urls does not help, nor does 
providing a revision option to the command.

   Thank you,
 Joe






This e-mail message (including any attachments) contains confidential, 
non-public information. It also may be protected by the attorney/client or 
other applicable privileges. It is intended to be communicated only to the 
designated recipient(s). Unauthorized use, reproduction, dissemination, or 
communication of this message or any information contained in this message is 
strictly prohibited and may be unlawful. If you are not an intended recipient 
of this message, please notify the sender promptly by e-mail or telephone at 
the sender's location indicated above or contact Shure Incorporated at 
i...@shure.com or 800-25-SHURE (800-257-4873).

RE: New subversion bug?

[Bert Huijben]

This is actually the designed implementation for many Subversion releases.

 

If the target doesn't exist, the source is copied to the target. If it does
exist it is copied below the target.

 

This matches the behavior of Unix's 'cp' and Windows' 'copy' for these
cases.

 

In your third case you find that the target below the passed target already
exists, and you get an error.

 

Bert

 

From: Croft, Joe [mailto:croft_...@shure.com] 
Sent: maandag 16 juni 2014 17:40
To: users@subversion.apache.org
Subject: New subversion bug?

 

Hi Yall,

 

I ran into the problem that when I do an svn copy command three times, it
behaves differently each time. The command line is:

 

svn cp https://server.com/Projects/project_a/trunk
https://server.com/Projects/project_a/tags/tag_a

 

The first time I run this I end up with what I expect, a directory with the
url of

 

https://server.com/Projects/project_a/tags/tag_a

 

which contains the files and folders which are under 'trunk' of the original
url.

 

The second time I run this I get an unexpected directory with the folder

 

https://server.com/Projects/project_a/tags/tag_a/trunk 

 

which also contain all of the folders and files which are under the 'trunk'
of the original url

 

On the third and subsequent executions of the same command, I get the error
I expected on the second invocation except for the url that it complains
about already existing. The error is

 

Svn: E160020: Path 'trunk' already exists. 

 

I really  the error "Svn: E160020: Path 'tag_a' already exists" on the
second invocation of the command.

 

I am running with svn server 1.6 on linux. The client can be windows or
linux 1.6 or 1.7. Adding a trailing slace ("/") to the urls does not help,
nor does providing a revision option to the command.

 

   Thank you,

 Joe

 

 

 


 This e-mail
message (including any attachments) contains confidential, non-public
information. It also may be protected by the attorney/client or other
applicable privileges. It is intended to be communicated only to the
designated recipient(s). Unauthorized use, reproduction, dissemination, or
communication of this message or any information contained in this message
is strictly prohibited and may be unlawful. If you are not an intended
recipient of this message, please notify the sender promptly by e-mail or
telephone at the sender's location indicated above or contact Shure
Incorporated at i...@shure.com   or 800-25-SHURE
(800-257-4873). 
--  

RE: New subversion bug?

[Croft, Joe]

Thank you, but it would be nice to have a command line option to turn off this 
feature.

-joe

From: Bert Huijben [mailto:b...@qqmail.nl]
Sent: Monday, June 16, 2014 11:13 AM
To: Croft, Joe; users@subversion.apache.org
Subject: RE: New subversion bug?

This is actually the designed implementation for many Subversion releases.

If the target doesn't exist, the source is copied to the target. If it does 
exist it is copied below the target.

This matches the behavior of Unix's 'cp' and Windows' 'copy' for these cases.

In your third case you find that the target below the passed target already 
exists, and you get an error.

Bert

From: Croft, Joe [mailto:croft_...@shure.com]
Sent: maandag 16 juni 2014 17:40
To: users@subversion.apache.org
Subject: New subversion bug?

Hi Yall,

I ran into the problem that when I do an svn copy command three times, it 
behaves differently each time. The command line is:

svn cp https://server.com/Projects/project_a/trunk 
https://server.com/Projects/project_a/tags/tag_a

The first time I run this I end up with what I expect, a directory with the url 
of

https://server.com/Projects/project_a/tags/tag_a

which contains the files and folders which are under 'trunk' of the original 
url.

The second time I run this I get an unexpected directory with the folder

https://server.com/Projects/project_a/tags/tag_a/trunk

which also contain all of the folders and files which are under the 'trunk' of 
the original url

On the third and subsequent executions of the same command, I get the error I 
expected on the second invocation except for the url that it complains about 
already existing. The error is

Svn: E160020: Path 'trunk' already exists.

I really  the error "Svn: E160020: Path 'tag_a' already exists" on the second 
invocation of the command.

I am running with svn server 1.6 on linux. The client can be windows or linux 
1.6 or 1.7. Adding a trailing slace ("/") to the urls does not help, nor does 
providing a revision option to the command.

   Thank you,
 Joe




 This e-mail 
message (including any attachments) contains confidential, non-public 
information. It also may be protected by the attorney/client or other 
applicable privileges. It is intended to be communicated only to the designated 
recipient(s). Unauthorized use, reproduction, dissemination, or communication 
of this message or any information contained in this message is strictly 
prohibited and may be unlawful. If you are not an intended recipient of this 
message, please notify the sender promptly by e-mail or telephone at the 
sender's location indicated above or contact Shure Incorporated at 
i...@shure.com or 800-25-SHURE (800-257-4873). 
  



This e-mail message (including any attachments) contains confidential, 
non-public information. It also may be protected by the attorney/client or 
other applicable privileges. It is intended to be communicated only to the 
designated recipient(s). Unauthorized use, reproduction, dissemination, or 
communication of this message or any information contained in this message is 
strictly prohibited and may be unlawful. If you are not an intended recipient 
of this message, please notify the sender promptly by e-mail or telephone at 
the sender's location indicated above or contact Shure Incorporated at 
i...@shure.com or 800-25-SHURE (800-257-4873).

Re: New subversion bug?

[Ben Reser]

On 6/16/14 8:26 PM, Croft, Joe wrote:
> Thank you, but it would be nice to have a command line option to turn off this
> feature.

Seems like a reasonable suggestion.  I'd suggest --no-target-directory which
mirrors the GNU cp option that provides this functionality.  Don't think the
various Windows commands have an equivalent.