Hi, Mark,

Von: Mark Phippard [mailto:markp...@gmail.com] 

> On Mon, Aug 22, 2011 at 6:00 AM, Markus Schaber <m.scha...@3s-software.com> 
> wrote:

>> We need to add a new directory including files and properties to a
>> subversion repository "in-place".
>> 
>> With SVN 1.6, the following did work: (I know that this is only an
>> artifact and was no documented / intended behavior.)
>> - Checkout the parent directory to a temporary place.
>> - create and svn add the data directory under the parent working copy.
>> - svn add and svn propset all the children we need in the working copy.
>> - svn commit the parent directory (to add everything in a single
>>   commit.)
>> - move the data directory to the intended working copy place.
>> - delete the temporary parent directory.
>>
>> With SVN 1.7, I only see a way to do this with 2 commits:
>> - svn remote add the data directory. (First commit)
>> - checkout the data directory
>> - fill the data directory with contents (files and properties)
>> - svn commit the data directory. (Second commit).
>> (This is analogeous to the "in-place import" in the FAQ.)
>>
>> Is it theoretically possible with the new working copy architecture to
>> allow the working copy root itself to be "scheduled for addition"?

> I am confused about why the exact same sequence of commands does not work for 
> you with 1.7.  What does the location of the .svn folder have to do with any 
> of this?

The "Detaching" by moving the subdirectory to the desired place and then 
throwing the parent directory will not work with SVN 1.7.

> The problem to me, does not seem to be the import, which you can do with one 
> commit just fine.  It seems to be that after it is done, you want to move 
> this folder somewhere else to use it?  That can be done using the detach 
> script to copy it to the new location:
> http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/detach.py 

We do not insist in the "detach" step. The "detach" step just was part of the 
workaround to get an inplace-import with SVN 1.6, just as the second commit is 
part our workaround for SVN 1.7.

We need an inplace-import as we did make the decision to store object metadata 
in SVN properties. (Maybe that design decision was wrong. Currently, we still 
could change that design, as we did not release yet. All this is part of our 
mapping of the CoDeSys project database to a file-and-directory tree as needed 
by subversion.) Another reason for the in-place import is that it makes no 
sense to transfer the data over the network twice.

And the "moving" of the workingcopy was simplified use case - in fact, the 
working copy is zipped and packed into the project database file when the 
project is closed, so that the .project file can be transferred as normal and 
carries the working copy with it in a piggyback style. When the project is 
opened again, the working copy is unzipped into a new temporary directory.

Detaching via a python script is nice, but it has the disadvantage that we 
would need to deliver cPython as part of our software. (We currently deliver 
IronPython, but this has no supported subversion bindings yet.) 


Best regards

Markus Schaber

___________________________
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax 
+49-831-54031-50

Email: m.scha...@3s-software.com | Web: http://www.3s-software.com 
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: 
http://www.3s-software.com/index.shtml?sample_projects

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade 
register: Kempten HRB 6186 | Tax ID No.: DE 167014915

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Reply via email to