Merge problem with different users

[Ungruhe, Michael]

Hi, 

 

We noticed the following problem:

 

We are usually working on the trunk, but for a change request we created a 
branch. Development continued on both, the trunk and the branch.

Some changes were made on the trunk including the deletion of some files, all 
changes were committed to the trunk. 

User A wanted to merge the changes from the trunk into the branch using the 
"svn merge" command. Everything went fine, all updates have been recognized, 
the deleted files have been deleted on the branch. The merged results have been 
committed to the branch.

After a while, another user (User B) wanted to merge changes made in the 
meantime from the trunk into the branch. 

He received the following messages for the files that have been deleted in the 
first merge (of User A): "Local delete, incoming delete upon merge". He marked 
the tree conflicts as resolved and checked in the merged version to the branch. 
The next time User B wanted to merge changes from the trunk to the branch, he 
received the same error messages for the same (deleted) files. He was not able 
to bring the branch to a state at which it could be reintegrated to the trunk.

When User A tried to do the merge, everything went fine and the branch could be 
reintegrated to the trunk.

After we noticed the same problem on different branches, we created a "merge 
user" who will be used to do the merging and reintegration as a work around.

 

Is this a known issue or is there another way of merging etc with different 
users?

We are using SVN 1.6.5 on CentOS 5

 

Thanks in advance and kind regards

Michael

Michael Ungruhe

Lead Consultant

T: +49 211 5355 513
F: +49 211 5355 99 513

CGI Information Systems and Management Consultants (Deutschland) GmbH
Niederkasseler Lohweg 175 - 40547 Düsseldorf - Germany
Registergericht/Company Number: AG Düsseldorf (HRB 51806) - 
Geschäftsführer/Managing Directors: Michael E. Roach, R. David Anderson, Donna 
Morea, Theodor Hirwatis, Faris Mohammed - Steuernummer/Tax No.: 103/5717/1949 | 
USt-Id.-Nr. DE 114 118 368 -
http://www.cgi.com
CONFIDENTIALITY NOTICE: Proprietary/Confidential Information belonging to CGI 
Group Inc. and its affiliates may be contained in this message. If you are not 
a recipient indicated or intended in this message (or responsible for delivery 
of this message to such person), or you think for any reason that this message 
may have been addressed to you in error, you may not use or copy or deliver 
this message to anyone else. In such case, you should destroy this message and 
are asked to notify the sender by reply email.

 

Re: Merge problem with different users

[Stefan Sperling]

On Fri, Sep 03, 2010 at 12:53:34AM -0700, Ungruhe, Michael wrote:
> Hi, 
> 
>  
> 
> We noticed the following problem:
> 
>  
> 
> We are usually working on the trunk, but for a change request we created a 
> branch. Development continued on both, the trunk and the branch.
> 
> Some changes were made on the trunk including the deletion of some files, all 
> changes were committed to the trunk. 
> 
> User A wanted to merge the changes from the trunk into the branch using the 
> "svn merge" command. Everything went fine, all updates have been recognized, 
> the deleted files have been deleted on the branch. The merged results have 
> been committed to the branch.
> 
> After a while, another user (User B) wanted to merge changes made in the 
> meantime from the trunk into the branch. 
> 
> He received the following messages for the files that have been deleted in 
> the first merge (of User A): "Local delete, incoming delete upon merge". He 
> marked the tree conflicts as resolved and checked in the merged version to 
> the branch. The next time User B wanted to merge changes from the trunk to 
> the branch, he received the same error messages for the same (deleted) files. 
> He was not able to bring the branch to a state at which it could be 
> reintegrated to the trunk.
> 
> When User A tried to do the merge, everything went fine and the branch could 
> be reintegrated to the trunk.
> 
> After we noticed the same problem on different branches, we created a "merge 
> user" who will be used to do the merging and reintegration as a work around.
> 
>  
> 
> Is this a known issue or is there another way of merging etc with different 
> users?
> 
> We are using SVN 1.6.5 on CentOS 5

Sounds like some users didn't commmit mergeinfo correctly.

What did the mergeinfo on the trunk look like after the first merge?
 svn propget -R -v svn:mergeinfo trunk_...@rev-of-first-merge-commit

What did the mergeinfo on the branch look like after the first merge?
 svn propget -R -v svn:mergeinfo branch_...@rev-of-first-merge-commit

What does the mergeinfo look like in all the other revisions where merges
were committed?

Why does your "merge user" fix the problem? Maybe that user is doing
merges differently than some of the developers did?

Stefan

SVN Functionality: loss of locks when switching to a branch

[REYNOLDS, Dylan]

My SVN versions - apologies if anything I write is out of date:
TortoiseSVN 1.6.5, Build 16974 - 32 Bit , 2009/08/20 08:13:46
Subversion 1.6.5,

I am currently working on a project with file that cannot be merged and hence 
require the use of locks and svn:needs-lock.

Even though we want to use locks we still also want to use branching.  This 
allows us to still have a buildable trunk, it keeps the logs of branch work and 
trunk work separate and it promotes good branch working practise for other 
projects where merging may be possible.

The ideal would be that the team could lock the trunk down while they work on 
their branch.  Then some other colleague could check out the trunk to build 
with but not edit the trunk.

Here is the problem:

If you have the trunk as your working copy.
You then take out locks on all non-mergable files so that the trunk can't be 
edited.
Next you branch the trunk and in the process switch to this branch.

Now as desired the trunk is locked.  If all files have svn-needs-lock then 
everything is as you wanted it to be.

However, now you have finished with the branch and you want to merge it to 
trunk.
So you switch back to the trunk.
BUT YOUR LOCKS HAVE DISAPPEARED from your working copy - in this working copy 
check out you no longer have the locks since (I assume) you're .svn folder has 
changed.
If you try to lock the files, even though according to the repository you 
actually hold the lock, you will be told that some user (you) has a lock on the 
file.

The solution is then to steal the lock back from yourself.  This doesn't seem 
right.  Particularly not to tell the team that in their normal working practise 
they have to steal their locks back.

In my opinion, if the lock exists in the repository, under your user name, then 
why can't this information be pushed in to your working copy when you make the 
update/switch/checkout?

A check should be performed for repository locks that belong to the username 
checking out (or switching) that working copy.  If the usernames match then you 
should get your lock, along with the files.

I understand that locking is an "extra" functionality of svn. However, it can 
be very useful for some files and it seems under supported in svn.

It would be even more useful if locks and the lock holder were pushed out to 
every user when they updated/checked out their working copy. This would resolve 
the above issue and also mean that all updated working copies would show that 
the file is locked by you or locked by someone else.

Kind Regards,

Dylan Reynolds


Dylan REYNOLDS
Software and Simulation Engineer
Simulation and Modelling - EDLIS
10X
Airbus in the UK




This e-mail and any attachment may contain confidential and/or privileged 
information. If you have received this e-mail and/or attachment in error, 
please notify the sender immediately and delete the e-mail and any attachment 
from your system. If you are not the intended recipient you must not copy, 
distribute, disclose or use the contents of the e-mail or any attachment. 
All e-mail sent to or from this address may be accessed by someone other than 
the recipient for system management and security reasons or for other lawful 
purposes. 
Airbus Operations Limited does not accept liability for any damage or loss 
which may be caused by software viruses. 
Airbus Operations Limited is registered in England and Wales under company 
number 3468788. The company's registered office is at New Filton House, Filton, 
Bristol, BS99 7AR.

Re: SVN Functionality: loss of locks when switching to a branch

[Ulrich Eckhardt]

On Friday 03 September 2010, REYNOLDS, Dylan wrote:
[locking a file and switching the WC loses the lock info for the WC]
> In my opinion, if the lock exists in the repository, under your user name,
> then why can't this information be pushed in to your working copy when you
> make the update/switch/checkout?

To which of all your multiple working copies do you want to push the lock? I'd 
say that SVN is right that it connects the lock to both the user and one 
specific working copy, otherwise you could commit changes from one of your 
WCs that conflict with changes in a different WC.


> A check should be performed for repository locks that belong to the
> username checking out (or switching) that working copy.  If the usernames
> match then you should get your lock, along with the files.

What SVN should IMHO do is tell you when an operation on a WC would break the 
association between a lock and that WC, like the switch seems to have done. 
It could even remember the lock and restore it when switching back. 
Otherwise, you don't have to use "switch" to create a branch or afterwards, 
you can also check out a new WC. Further, it would make sense to lock the 
file in both the trunk and the branch, and do both in separate working 
copies. Lastly, educating people why they must steal their own lock (bound to 
working copy, not just user) should be pretty easy.


> I understand that locking is an "extra" functionality of svn. However, it
> can be very useful for some files and it seems under supported in svn.

No doubt about that, I believe that initially it was seen as wrong approach by 
many people but is now recognised as valuable and necessary feature. It's not 
a second-class feature.

Cheers!

Uli

-- 
ML: http://subversion.tigris.org/mailing-list-guidelines.html
FAQ: http://subversion.tigris.org/faq.html
Docs: http://svnbook.red-bean.com/

Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
Sator 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. Sator Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

Re: SVN 1.6.12 crash on merge.

[Andy Levy]

Please don't reply to me, reply to all to keep discussion on the mailing list.

I believe the Slik maintainer posted yesterday that there was a
problem with the 1.6.12 build and a new version is on the way.

On Fri, Sep 3, 2010 at 05:01, Pavel Ivanov  wrote:
> The bug does not reproduce with the collabnet binaries v1.6.12.
>
> -Original Message-
> From: Andy Levy [mailto:andy.l...@gmail.com]
> Sent: Tuesday, August 24, 2010 10:26 PM
> To: Ivanov, Pavel
> Cc: users@subversion.apache.org
> Subject: Re: SVN 1.6.12 crash on merge.
>
> On Tue, Aug 24, 2010 at 08:55, Pavel Ivanov  wrote:
>>
>
> When reporting a crash, it is much more helpful if you can attach a
> sample repository & exact steps (preferably a script) which will
> reliably reproduce the issue. Just attaching dumps & logs without
> explaining how you got there is going to make things difficult for
> someone trying to help you.
>
> Also, this mailing list is for the "standard" release of Subversion.
> Make sure you contact the SlikSVN maintainers, as they're the ones who
> actually compiled the version you're using. Their
> settings/libraries/compilers may differ from the vanilla Subversion,
> resulting in bugs unique to that distribution.
>

Re: SVN 1.6.12 crash on merge.

[ankush chadha]

I also faced the same issue with slikSVN and it was throwing a dump but when I 
switched to colabnet binaries, it was working fine.

Ankush 


  

Re: SVN 1.6.12 crash on merge.

[Andy Levy]

On Fri, Sep 3, 2010 at 09:02, ankush chadha  wrote:
>
> I also faced the same issue with slikSVN and it was throwing a dump but when 
> I switched to colabnet binaries, it was working fine.

http://svn.haxx.se/users/archive-2010-09/0065.shtml

> 
> From: Andy Levy ;
> To: Pavel Ivanov ; ;
> Subject: Re: SVN 1.6.12 crash on merge.
> Sent: Fri, Sep 3, 2010 3:36:25 AM
>
> Please don't reply to me, reply to all to keep discussion on the mailing list.
>
> I believe the Slik maintainer posted yesterday that there was a
> problem with the 1.6.12 build and a new version is on the way.
>
> On Fri, Sep 3, 2010 at 05:01, Pavel Ivanov  wrote:
> > The bug does not reproduce with the collabnet binaries v1.6.12.
> >
> > -Original Message-
> > From: Andy Levy [mailto:andy.l...@gmail.com]
> > Sent: Tuesday, August 24, 2010 10:26 PM
> > To: Ivanov, Pavel
> > Cc: users@subversion.apache.org
> > Subject: Re: SVN 1.6.12 crash on merge.
> >
> > On Tue, Aug 24, 2010 at 08:55, Pavel Ivanov  
> > wrote:
> >>
> >
> > When reporting a crash, it is much more helpful if you can attach a
> > sample repository & exact steps (preferably a script) which will
> > reliably reproduce the issue. Just attaching dumps & logs without
> > explaining how you got there is going to make things difficult for
> > someone trying to help you.
> >
> > Also, this mailing list is for the "standard" release of Subversion.
> > Make sure you contact the SlikSVN maintainers, as they're the ones who
> > actually compiled the version you're using. Their
> > settings/libraries/compilers may differ from the vanilla Subversion,
> > resulting in bugs unique to that distribution.
> >
>

Re: Scripting an svn:externals change

[BRM]

- Original Message 

> From: Ryan Schmidt 
> > $ cat Example1.dump | sed 
> >  's/file:\/\/\/svnTest\/Example1/file:\/\/\/svnTest\/Example2/' > 
> >  Example1-edited.dump
> Do not use sed to edit a dumpfile. Use a tool  designed for the task, like  
>svndumptool.
> http://svn.borg.ch/svndumptool/

Why? B/c it might change data in files too? That's actually something I want 
done.
My prime repository has some scripts in it that store the repository 
information 
for auto-checkouts as part of build environments, and I want those changed too 
- 
not just the svn:externals.

Or would sed 'break' the dump file format? svndumptool does look useful to 
verify that sed did exactly what I wanted - standard diff won't work well on a 
2.1 GB dumpfile.
 
> > 5. Load the  edited dump into a new repository (Example2)
> > 
> > $ cd  /svnTest
> > $ svnadmin create Example2
> > $ svnadmin load Example2  < Example1-edited.dump
> Because this repository is now different than  it was before (the history has 
>been edited), you must give the new repository a  new UUID.
> svnadmin load --ignore-uuid Example2 <  Example1-edited.dump

I wouldn't say 'must' but 'should' - as in 'highly recommended'.

> Since the UUID has changed, everyone must check  out new working copies; it 
> is 
>not possible to update or switch existing working  copies to this new changed 
>repository.

Or I could just ignore the history, and just go back to my original question of 
changing the values.

As I said, I need to make this as seamless as possible for everyone - 
preferably 
doing an 'svn relocate'/'svn update' on the working copies.

Question: If I checked them out again would the client realize that I have a 
series of files locked and retain the locks on the new working copy? (That 
would 
be a PITA to track down if it didn't.)

TIA,

Ben

Re: Scripting an svn:externals change

[Andy Levy]

On Fri, Sep 3, 2010 at 09:36, BRM  wrote:
> - Original Message 
>
>> From: Ryan Schmidt 
>> > $ cat Example1.dump | sed
>> >  's/file:\/\/\/svnTest\/Example1/file:\/\/\/svnTest\/Example2/' >
>> >  Example1-edited.dump
>> Do not use sed to edit a dumpfile. Use a tool  designed for the task, like
>>svndumptool.
>> http://svn.borg.ch/svndumptool/
>
> Why? B/c it might change data in files too? That's actually something I want
> done.
> My prime repository has some scripts in it that store the repository 
> information
> for auto-checkouts as part of build environments, and I want those changed 
> too -
> not just the svn:externals.
>
> Or would sed 'break' the dump file format? svndumptool does look useful to
> verify that sed did exactly what I wanted - standard diff won't work well on a
> 2.1 GB dumpfile.

If you modify the contents as well, it'll break the dumpfile. The
dumpfile contains an MD5 hash of each file for integrity checking.

Re: Scripting an svn:externals change

[Daniel Shahaf]

BRM wrote on Fri, Sep 03, 2010 at 06:36:05 -0700:
> - Original Message 
> 
> > From: Ryan Schmidt 
> > > $ cat Example1.dump | sed 
> > >  's/file:\/\/\/svnTest\/Example1/file:\/\/\/svnTest\/Example2/' > 
> > >  Example1-edited.dump
> > Do not use sed to edit a dumpfile. Use a tool  designed for the task, like  
> > svndumptool.
> > http://svn.borg.ch/svndumptool/
> 
> Why?

Because dump files have structure --- e.g., they contain checksums (length,
md5, sha1) of their contents.

Failed to remove file fetched by svn:externals

[Matias E. Fernandez]

Hello

A file imported via svn:externals definition fails being removed after
deleting the svn:externals property with propdel, or removing the 
specific entry with propedit.

Details see below.

Regards
Matias

p.s.: please cc me, as I am not subscribed to this mailing list.

$ svn --version
svn, version 1.6.12 (r955767)
   compiled Jul 13 2010, 13:33:56

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

The following repository access (RA) modules are available:

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

Steps to reproduce this bug:

~/Desktop/mysvnrepo$ svnadmin create test
~/Desktop/mysvnrepo$ svn co file:///Users/pisco/Desktop/mysvnrepo/test/ sandbox
Checked out revision 0.
~/Desktop/mysvnrepo$ cd sandbox/
~/<1>/mysvnrepo/sandbox(0)$ mkdir -p a/b/c
~/<1>/mysvnrepo/sandbox(0)$ cd a/b/c/
~/<4>/b/c$ touch bla.txt
~/<4>/b/c$ cd ../../..
~/<1>/mysvnrepo/sandbox(0)$ svn add a/
A a
A a/b
A a/b/c
A a/b/c/bla.txt
~/<1>/mysvnrepo/sandbox(0M)$ mkdir x
~/<1>/mysvnrepo/sandbox(0M)$ svn add x/
A x
~/<1>/mysvnrepo/sandbox(0M)$ svn commit .
Adding a
Adding a/b
Adding a/b/c
Adding a/b/c/bla.txt
Adding x
Transmitting file data .
Committed revision 1.
~/<1>/mysvnrepo/sandbox(0:1)$ svn propedit svn:externals x
Set new value for property 'svn:externals' on 'x'
~/<1>/mysvnrepo/sandbox(0:1M)$ svn up x

Fetching external item into 'x/bla.txt'
Ex/bla.txt
Updated external to revision 1.

Updated to revision 1.
~/<1>/mysvnrepo/sandbox(0:1M)$ svn commit 
Sendingx

Committed revision 2.
~/<1>/mysvnrepo/sandbox(0:2)$ svn propdel svn:externals x
property 'svn:externals' deleted from 'x'.
~/<1>/mysvnrepo/sandbox(0:2M)$ svn up
At revision 2.
~/<1>/mysvnrepo/sandbox(2M)$ svn st
 M  x
X   x/bla.txt
~/<1>/mysvnrepo/sandbox(2M)$ svn commit .
Sendingx

Committed revision 3.
~/<1>/mysvnrepo/sandbox(2:3)$ svn up
At revision 3.
~/<1>/mysvnrepo/sandbox(3)$ svn st
X   x/bla.txt
~/<1>/mysvnrepo/sandbox(3)$ svn rm x/bla.txt 
svn: Cannot remove the file external at 'x/bla.txt'; please propedit or propdel 
the svn:externals description that created it
~/<1>/mysvnrepo/sandbox(3)$ rm x/bla.txt 
~/<1>/mysvnrepo/sandbox(3M)$ svn st
!   X   x/bla.txt   

Re: Failed to remove file fetched by svn:externals

[Stefan Sperling]

On Fri, Sep 03, 2010 at 04:20:14PM +0200, Matias E. Fernandez wrote:
> Hello
> 
> A file imported via svn:externals definition fails being removed after
> deleting the svn:externals property with propdel, or removing the 
> specific entry with propedit.
> 
> Details see below.
> 
> Regards
> Matias
> 
> p.s.: please cc me, as I am not subscribed to this mailing list.

This is a known issue: http://subversion.tigris.org/issues/show_bug.cgi?id=3351

Stefan

Understanding svn:eol-style interactions with other properties

[stevecoh1]

I am trying to adapt a legacy system written in C to use SVN for version 
control. 

This legacy system has components that are built and run on linux and also 
other components that are built and run on MS-DOS (yes, MS-DOS, although 
eventually it's going away!). Development will, for the most part, take place 
on Windows platforms. Builds will take place on linux and DOS systems. The 
build process for the DOS components is able to account for unix line feeds and 
react appropriately. However, there are a few directories whose files must 
retain their DOS CRLFs. So my thought is to go svn propset svn:eol-style=native 
globally and svn propset svn:eol-style=CRLF for those exceptions. 

So far so good, but now we come to my main question. 

There are also directories containing some unusual kinds of non-source stuff 
including DOS executables and libraries. When these are brought under SVN, SVN 
correctly guesses their svn:mime-type (at least most of the time) as 
application/octet-stream and also adds an svn:executable property. It seems 
that the presence of either or both (which?) of these properties prevents the 
global assignment of svn:eol-style which would otherwise have been applied to 
these files by the propset operation described above. Is this the case and are 
there any other interactions between svn:eol-style and other properties that I 
need to know about. Is there detailed information about the functioning of svn 
propset in these cases? The svn manual does not descend to this level of 
detail. 

Thanks. 

svn --recursive propset fails "Is a directory"

[stevecoh1]

Using the subversive eclipse plugin, I am able to do the equivalent of 
svn --recursive propset svn:eol-style native . 

But on the command line itself this fails with 

svn: Can't read file 'subdir': Is a directory 

What is the value of the --recursive switch if it doesn't handle this? Or am I 
missing something? 

Re: Scripting an svn:externals change

[Ryan Schmidt]

On Sep 3, 2010, at 08:36, BRM wrote:

>> Do not use sed to edit a dumpfile. Use a tool  designed for the task, like  
>> svndumptool.
>> http://svn.borg.ch/svndumptool/
> 
> Why? B/c it might change data in files too? That's actually something I want 
> done.
> My prime repository has some scripts in it that store the repository 
> information 
> for auto-checkouts as part of build environments, and I want those changed 
> too - 
> not just the svn:externals.
> 
> Or would sed 'break' the dump file format? svndumptool does look useful to 
> verify that sed did exactly what I wanted - standard diff won't work well on 
> a 
> 2.1 GB dumpfile.

As others said, because if you change the content of files, the checksums won't 
match. Just use svndumptool to change the svn:externals properties, and for any 
file content changes, make them and commit them from a working copy as normal.


>>> 5. Load the  edited dump into a new repository (Example2)
>>> 
>>> $ cd  /svnTest
>>> $ svnadmin create Example2
>>> $ svnadmin load Example2  < Example1-edited.dump
>> Because this repository is now different than  it was before (the history 
>> has 
>> been edited), you must give the new repository a  new UUID.
>> svnadmin load --ignore-uuid Example2 <  Example1-edited.dump
> 
> I wouldn't say 'must' but 'should' - as in 'highly recommended'.

If the content of the new repository is different from the content of the old 
repository (and it is, if you changed the properties), then you must give them 
different UUIDs. That is the sole purpose of the UUID -- to identify when 
repositories differ.


>> Since the UUID has changed, everyone must check  out new working copies; it 
>> is 
>> not possible to update or switch existing working  copies to this new 
>> changed 
>> repository.
> 
> Or I could just ignore the history, and just go back to my original question 
> of 
> changing the values.
> 
> As I said, I need to make this as seamless as possible for everyone - 
> preferably 
> doing an 'svn relocate'/'svn update' on the working copies.

And as I said, dump and load and changing UUID requires checking out new 
working copies. You cannot relocate or update existing working copies. If 
that's too restrictive, then yes, you'll have to skip the dump and load, just 
change the externals in HEAD, and accept that you can't check out a past 
revision and have the externals work.


> Question: If I checked them out again would the client realize that I have a 
> series of files locked and retain the locks on the new working copy? (That 
> would 
> be a PITA to track down if it didn't.)

I'm not sure exactly what you meant (checked out new working copies? from the 
new repository?), but note that the dump format does not include information 
about hook scripts, config files or locks. If you dump and load, the new 
repository will have the default hook script templates (so, no hook scripts), 
the default configuration, and nothing locked. But I think you can manually 
bring the relevant files from the old repository to the new one to preserve 
this data.

Re: Scripting an svn:externals change

[Daniel Shahaf]

Ryan Schmidt wrote on Fri, Sep 03, 2010 at 15:29:17 -0500:
> the dump format does not include information
> about hook scripts, config files or locks. If you dump and load, the new
> repository will have the default hook script templates (so, no hook scripts),
> the default configuration, and nothing locked. But I think you can manually
> bring the relevant files from the old repository to the new one to preserve
> this data.

For hooks and config files, yes.

Re: Scripting an svn:externals change

[Ryan Schmidt]

On Sep 3, 2010, at 16:51, Daniel Shahaf wrote:

> Ryan Schmidt wrote on Fri, Sep 03, 2010 at 15:29:17 -0500:
> 
>> the dump format does not include information
>> about hook scripts, config files or locks. If you dump and load, the new
>> repository will have the default hook script templates (so, no hook scripts),
>> the default configuration, and nothing locked. But I think you can manually
>> bring the relevant files from the old repository to the new one to preserve
>> this data.
> 
> For hooks and config files, yes.

I thought I heard others say you could copy the db/locks directory to preserve 
locks, too. Will that not work?

Re: Scripting an svn:externals change

[Daniel Shahaf]

Ryan Schmidt wrote on Fri, Sep 03, 2010 at 16:57:31 -0500:
> 
> On Sep 3, 2010, at 16:51, Daniel Shahaf wrote:
> 
> > Ryan Schmidt wrote on Fri, Sep 03, 2010 at 15:29:17 -0500:
> > 
> >> the dump format does not include information
> >> about hook scripts, config files or locks. If you dump and load, the new
> >> repository will have the default hook script templates (so, no hook 
> >> scripts),
> >> the default configuration, and nothing locked. But I think you can manually
> >> bring the relevant files from the old repository to the new one to preserve
> >> this data.
> > 
> > For hooks and config files, yes.
> 
> I thought I heard others say you could copy the db/locks directory to
> preserve locks, too. Will that not work?

The API does not promise that copying db/locks will work.


And if someone tries that anyway?  In general, I think the answer to
your question is the same as the answer to the general "Can I rsync my
repository directory?" question:

* under FSFS, the API doesn't allow it but it might work under certain
  conditions.

* under BDB, db/locks is a BDB database,
  and you probably know better than me when it is/isn't safe to just
  copy those :-).

Re: Scripting an svn:externals change

[BRM]

- Original Message 

> From: Ryan Schmidt 
> To: BRM 
> >> Since  the UUID has changed, everyone must check  out new working copies; 
> >> it 
>is 
>
> >> not possible to update or switch existing working  copies to  this new 
>changed 
>
> >> repository.
> > 
> > Or I could just  ignore the history, and just go back to my original 
> > question 
>of 
>
> >  changing the values.
> > 
> > As I said, I need to make this as seamless  as possible for everyone - 
>preferably 
>
> > doing an 'svn relocate'/'svn  update' on the working copies.
> 
> And as I said, dump and load and changing  UUID requires checking out new 
>working copies.
> You cannot relocate or update  existing working copies. If that's too 
>restrictive, then yes,
> you'll have to  skip the dump and load, just change the externals in HEAD, 
> and 
>accept
> that you  can't check out a past revision and have the externals work.

Having the history broken is not much of a problem that way. It just would have 
been nice to have it work well too.
Though, couldn't I setup a script to modify the svn:externals via the pset 
--revprop option?
Any how...I've got a lot of work ahead regardless.
 
> >  Question: If I checked them out again would the client realize that I have 
> > a 
>
> > series of files locked and retain the locks on the new working copy?  (That 
>would 
>
> > be a PITA to track down if it didn't.)
> 
> I'm not sure  exactly what you meant (checked out new working copies?
> from the new  repository?), but note that the dump format does not include
> information about  hook scripts, config files or locks. If you dump and load,
> the new repository  will have the default hook script templates (so, no hook
> scripts), the default  configuration, and nothing locked. But I think you can
> manually bring the  relevant files from the old repository to the new one to 
>preserve this  data.
> 

Okay - the basic situation is that I have a branch in SVN that was under 
migration. It was a port of our CVS into SVN and needed to be split up into 
separate projects which requires a lot of work to do.
So I had a working copy where I locked files that I had moved to the new 
structure to help keep from editing those files in the old structure, and it'll 
be a PITA to figure out which files were moved and locked between the two.
At least I still have the working copy. If they don't transfer, okay - I just 
have to go through the old working copy and relock them in a new working copy.

(I had to use locks as I couldn't just remove the files due to breaking other 
projects.)

Thanks - I think I have my plan of action now - it'll just take a while to 
implement. If I can get apache to do the proxy thing (http://silmor.de/49) then 
I can at least get back to a working state where we can move things about with 
our existing working copies - make sure all changes are in, and are at a good 
place to re-download them.

Sadly this all occurred due to a server crash, so it was rather unplanned 
though 
it didn't surprise some of us.

Thanks all!

Ben

Re: Scripting an svn:externals change

[Ryan Schmidt]

On Sep 3, 2010, at 17:52, BRM wrote:

>> You cannot relocate or update  existing working copies. If that's too 
>> restrictive, then yes,
>> you'll have to  skip the dump and load, just change the externals in HEAD, 
>> and 
>> accept
>> that you  can't check out a past revision and have the externals work.
> 
> Having the history broken is not much of a problem that way. It just would 
> have 
> been nice to have it work well too.
> Though, couldn't I setup a script to modify the svn:externals via the pset 
> --revprop option?
> Any how...I've got a lot of work ahead regardless.

No; svn:externals is a versioned property, not a revision property.

Re: Scripting an svn:externals change

[BRM]

- Original Message 

> From: Ryan Schmidt 
> To: BRM 
> On Sep 3, 2010, at 17:52, BRM wrote:
> >> You cannot relocate or  update  existing working copies. If that's too 
> >> restrictive,  then yes,
> >> you'll have to  skip the dump and load, just change  the externals in 
> >> HEAD, 
>and 
>
> >> accept
> >> that you  can't  check out a past revision and have the externals work.
> > Having  the history broken is not much of a problem that way. It just would 
>have 
>
> > been nice to have it work well too.
> > Though, couldn't I setup a  script to modify the svn:externals via the pset 
> > --revprop  option?
> > Any how...I've got a lot of work ahead regardless.
> No;  svn:externals is a versioned property, not a revision property.

Thanks.

I did get the the Apache proxy stuff working. Still got a lot to do, but at 
least we can function now.

Thanks!

Ben