AW: Single-commit import with properties and SVN 1.7

Hi, Mark,

Von: Mark Phippard [mailto:markphip_at_gmail.com]

> On Mon, Aug 22, 2011 at 6:00 AM, Markus Schaber <m.schaber_at_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.schaber@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/