Re: differences in dump/load/dump cycle

[Nico Kadel-Garcia]

On Wed, Aug 3, 2016 at 2:16 AM, Ryan Schmidt
 wrote:
>
> On Aug 2, 2016, at 9:54 PM, Nico Kadel-Garcia wrote:
>
>> On Tue, Aug 2, 2016 at 7:15 AM, Ivan Zhakov wrote:
>>
>> [dump/load cycles omitted]
>>
>> Please note. This sort of pernicious bug is why I suggest takeing a
>> clean export/import when moving to significantly newer versions, or
>> significantly new project versions, for Subversion repositories. Don't
>> hurt yourself trying to preserve burdensome, possibly flawed history
>> you *do not need*.
>
> PLEASE STOP.

Sorry, Ryan, but it needed saying.

Re: differences in dump/load/dump cycle

[Ryan Schmidt]

On Aug 3, 2016, at 7:54 AM, Nico Kadel-Garcia wrote:

> On Wed, Aug 3, 2016 at 2:16 AM, Ryan Schmidt wrote:
>> 
>> On Aug 2, 2016, at 9:54 PM, Nico Kadel-Garcia wrote:
>> 
>>> On Tue, Aug 2, 2016 at 7:15 AM, Ivan Zhakov wrote:
>>> 
>>> [dump/load cycles omitted]
>>> 
>>> Please note. This sort of pernicious bug is why I suggest takeing a
>>> clean export/import when moving to significantly newer versions, or
>>> significantly new project versions, for Subversion repositories. Don't
>>> hurt yourself trying to preserve burdensome, possibly flawed history
>>> you *do not need*.
>> 
>> PLEASE STOP.
> 
> Sorry, Ryan, but it needed saying.

No. I understand you have personal experiences with transferring history that 
have led you to prefer not to do so, but most of the Subversion developers and 
other members of this list do not share your views on this matter and I ask you 
again to refrain from working this opinion into every thread on this mailing 
list. The one-time existence of a bug in a feature does not mean that one 
should forever avoid using such a feature even after the bug has been fixed. 
And just because something like transferring history can be difficult to get 
right does not mean that the correct answer for everyone is not to try to do so.

Re: differences in dump/load/dump cycle

[Nico Kadel-Garcia]

On Wed, Aug 3, 2016 at 9:02 AM, Ryan Schmidt
 wrote:
>
> On Aug 3, 2016, at 7:54 AM, Nico Kadel-Garcia wrote:
>
>> On Wed, Aug 3, 2016 at 2:16 AM, Ryan Schmidt wrote:
>>>
>>> On Aug 2, 2016, at 9:54 PM, Nico Kadel-Garcia wrote:
>>>
 On Tue, Aug 2, 2016 at 7:15 AM, Ivan Zhakov wrote:

 [dump/load cycles omitted]

 Please note. This sort of pernicious bug is why I suggest takeing a
 clean export/import when moving to significantly newer versions, or
 significantly new project versions, for Subversion repositories. Don't
 hurt yourself trying to preserve burdensome, possibly flawed history
 you *do not need*.
>>>
>>> PLEASE STOP.
>>
>> Sorry, Ryan, but it needed saying.
>
> No. I understand you have personal experiences with transferring history that 
> have led you to prefer not to do so, but most of the Subversion developers 
> and other members of this list do not share your views on this matter and I 
> ask you again to refrain from working this opinion into every thread on this 
> mailing list. The one-time existence of a bug in a feature does not mean that 
> one should forever avoid using such a feature even after the bug has been 
> fixed. And just because something like transferring history can be difficult 
> to get right does not mean that the correct answer for everyone is not to try 
> to do so.

I don't insist on it: it's not always the correct answer. But it's not
the only time dump/load has suffered from bugs, and I'm sure it won't
be the last. In many cases it can save a great deal of work and should
be considered as one of the first options for complex migrations,
instead of the very last, for reasons I've mentioned before.

For new people: I've mentioned doing an svn export/import to a new
repository, instead of an svnadmin dump/load, as a useful migraiton
approach on various occasions for years now. It does discard history,
but it's the cleanest way to dump unwanted content and make a clean
start with a new layout. It was a potentially useful approach that
hadn't been mentioned for this thread, and  I felt that Stefan (and
others faced with expensive, potentially dangerous svnadmin dump/load
cycles) should keep it in mind for their next migration.

Re: differences in dump/load/dump cycle

[Stefan Hett]

On 8/3/2016 3:40 PM, Nico Kadel-Garcia wrote:

On Wed, Aug 3, 2016 at 9:02 AM, Ryan Schmidt
 wrote:

On Aug 3, 2016, at 7:54 AM, Nico Kadel-Garcia wrote:


On Wed, Aug 3, 2016 at 2:16 AM, Ryan Schmidt wrote:

On Aug 2, 2016, at 9:54 PM, Nico Kadel-Garcia wrote:


On Tue, Aug 2, 2016 at 7:15 AM, Ivan Zhakov wrote:

[dump/load cycles omitted]

Please note. This sort of pernicious bug is why I suggest takeing a
clean export/import when moving to significantly newer versions, or
significantly new project versions, for Subversion repositories. Don't
hurt yourself trying to preserve burdensome, possibly flawed history
you *do not need*.

PLEASE STOP.

Sorry, Ryan, but it needed saying.

No. I understand you have personal experiences with transferring history that 
have led you to prefer not to do so, but most of the Subversion developers and 
other members of this list do not share your views on this matter and I ask you 
again to refrain from working this opinion into every thread on this mailing 
list. The one-time existence of a bug in a feature does not mean that one 
should forever avoid using such a feature even after the bug has been fixed. 
And just because something like transferring history can be difficult to get 
right does not mean that the correct answer for everyone is not to try to do so.

[...]

For new people: I've mentioned doing an svn export/import to a new
repository, instead of an svnadmin dump/load, as a useful migraiton
approach on various occasions for years now. It does discard history,
but it's the cleanest way to dump unwanted content and make a clean
start with a new layout.
And here is where IMHO the flaw in your argument lies: The assumption 
that the data you are discarding is unwanted.
Especially by suggesting new people to discard these information you are 
neglecting the fact that especially this user group is likely to have 
less experience with versioning systems than you or others would have 
and are possibly not in a position to correctly evaluate/realize what 
the impact of the discard will be for their particular case/needs.


You are focusing again on "only" losing the history data (which, I 
believe I've stated before, is IMHO one (if not THE ONE) most important 
data in a version system), while you actually will drop a lot more. 
Especially in the scenario you are now suggesting to perform an 
export/import process over a dump/load process when >upgrading< from one 
to another major subversion version (rather than doing a migration from 
one to another CVS).
In this case you will loose all the additional data SVN uses/collected, 
not only the history. Mostly I'm referring here to the SVN properties. 
Depending on the integration/use of this data, you'd break the 
integration in the infrastructure for example.

It was a potentially useful approach that
hadn't been mentioned for this thread, and  I felt that Stefan (and
others faced with expensive, potentially dangerous svnadmin dump/load
cycles) should keep it in mind for their next migration.
Sorry but I can't share your opinion about svnadmin dump/load being 
potentially dangerous --- at least not in that this is more dangerous 
than a simple export/import with regards to data consistency.

To perform a dump load and then verify the integrity you would do:
dump -> load -> dump -> compare old vs. new dump
If there are differences between the dumps (which really normally 
shouldn't be the case) you determine where the difference are coming 
from. The mailing list will provide you with the necessary support to 
evaluate the impact of the difference you see.


In your export/import approach you would do:
export -> import -> export -> compare old vs. new export
And like with the dump/load/dump approach above, if you see a difference 
between the two exports you would then investigate their cause.


Without the final verification step (in both approaches) you certainly 
can not be more confident that the process worked flawlessly and you 
ended up with what you want.
So once more: I'm sorry, but I really can't even to the slightest share 
your believe in that export/import is anywhere 
better/easier/more-suitable (in the general case) than a dump/load-cycle.


As said before: there might be very specific cases where this might be 
preferable over complete data migration step. But I can't imagine a 
single case where this would be preferable over a dump/load/dump cycle.


--
Regards,
Stefan Hett, Developer/Administrator

EGOSOFT GmbH, Heidestrasse 4, 52146 Würselen, Germany
Tel: +49 2405 4239970, www.egosoft.com
Geschäftsführer: Bernd Lehahn, Handelsregister Aachen HRB 13473

Can svndumpfilter exclude specific named nodes only ?

[Kerry, Richard]

My understanding from the documentation is that svndumpfilter may be requested 
to exclude all nodes whose names have a specific prefix (ie this will exclude 
the named node and all its children).

My specific requirement is to exclude specific named nodes (and not their 
children).  Is it possible to request svndumpfilter to do this ?



The reason for this is that I am using cvs2svn to convert projects that need to 
end up inserting files/nodes within an existing repo tree.  In this case the 
dump file produced will include all nodes down from the root to the folder I am 
specifically interested in adding.  This includes Root, Root/trunk, Root/tags, 
Root/branches, which already exist ('Root' here being just an example of the 
name at the top of the tree).  When I attempt to load this using svnadmin load 
it aborts as these already exist.  So I need them not to be present in the dump 
(or some significantly different approach).



At the moment I can manually edit them out, as there aren't many, which results 
in the tree as I want it (*), but I wondered if I could get svndumpfilter to do 
the job for me.



Regards,

Richard.





(*) Almost, but I'll ask about that separately.





Richard Kerry
BNCS Engineer, SI SOL Telco & Media Vertical Practice
T: +44 (0)20 3618 2669
M: +44 (0)7812 325518
4 Triton Square, Regent’s Place, London NW1 3HG
richard.ke...@atos.net


This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, the Atos group liability cannot be triggered for the 
message content. Although the sender endeavours to maintain a computer 
virus-free network, the sender does not warrant that this transmission is 
virus-free and will not be liable for any damages resulting from any virus 
transmitted.
Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading 
names used by the Atos group. The following trading entities are registered in 
England and Wales: Atos IT Services UK Limited (registered number 01245534), 
Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited 
(registered number 08514184) and Canopy The Open Cloud Company Limited 
(registration number 08011902). The registered office for each is at 4 Triton 
Square, Regent’s Place, London, NW1 3HG.The VAT No. for each is: GB232327983.

This e-mail and the documents attached are confidential and intended solely for 
the addressee, and may contain confidential or privileged information. If you 
receive this e-mail in error, you are not authorised to copy, disclose, use or 
retain it. Please notify the sender immediately and delete this email from your 
systems. As emails may be intercepted, amended or lost, they are not secure. 
Atos therefore can accept no liability for any errors or their content. 
Although Atos endeavours to maintain a virus-free network, we do not warrant 
that this transmission is virus-free and can accept no liability for any 
damages resulting from any virus transmitted. The risks are deemed to be 
accepted by everyone who communicates with Atos by email.

Re: Can svndumpfilter exclude specific named nodes only ?

[Stefan Hett]

Hi Richard,

On 8/3/2016 5:35 PM, Kerry, Richard wrote:


My understanding from the documentation is that svndumpfilter may be 
requested to exclude all nodes whose names have a specific prefix (ie 
this will exclude the named node and all its children).


My specific requirement is to exclude specific named nodes (and not 
their children).  Is it possible to request svndumpfilter to do this ?


The reason for this is that I am using cvs2svn to convert projects 
that need to end up inserting files/nodes within an existing repo 
tree.  In this case the dump file produced will include all nodes down 
from the root to the folder I am specifically interested in adding.  
This includes Root, Root/trunk, Root/tags, Root/branches, which 
already exist ('Root' here being just an example of the name at the 
top of the tree).  When I attempt to load this using svnadmin load it 
aborts as these already exist.  So I need them not to be present in 
the dump (or some significantly different approach).


At the moment I can manually edit them out, as there aren't many, 
which results in the tree as I want it (*), but I wondered if I could 
get svndumpfilter to do the job for me.


Regards,

Richard.

(*) Almost, but I'll ask about that separately.


Atm I can think of the following way (hope I got your requirements correct):
split up the load into separate chunks.
1. import everything excluding the whole Root-node - using dumpfilter 
exclude
2. import the separate child-nodes (aka: Root/branches/) using 
dumpfilter include in combination with svnadmin load --parent-dir [Dir] 
(aka: svnadmin load --parentdir [Dir]


Would that solve your case?

--
Regards,
Stefan Hett

Bad error message if target repository directory does not exist

[Doug Robinson]

Folks:

The issue is when create copy/branch/tag from a local working copy
path using "svn copy", if the parent path of the copying target
does not exist, the "svn copy" command fails with a misleading error
message saying that the copy source (working copy directory) "is out
of date" while that is not the case.

The reproduce case (both client and server at 1.9.4):

# svn info
Path: .
Working Copy Root Path: /root/repo05
URL: http://192.168.56.202:8081/svn/repo05/trunk
Relative URL: ^/trunk
Repository Root: http://192.168.56.202:8081/svn/repo05
Repository UUID: deadbeef-b0b0-ca1f-f0f0-123456789abc
Revision: 1
Node Kind: directory
Schedule: normal
Last Changed Author: user01
Last Changed Rev: 1
Last Changed Date: 2016-07-29 15:37:02 +0800 (Fri, 29 Jul 2016)
# svn ls ^/branches
# svn cp -mm . ^/branches/test/br1
Adding copy of.
svn: E155011: Commit failed (details follow):
svn: E155011: Directory '/root/repo05/trunk' is out of date
svn: E160013: File not found: transaction '1-2', path '/branches/test/br1'
# svn mkdir -mm ^/branches/test
Committing transaction...
Committed revision 2.
# svn cp -mm . ^/branches/test/br1
Adding copy of.
Committing transaction...
Committed revision 3.

The error message certainly confuses the issue.

Thank you.

Doug
-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.