Webware for Python

On 20:47 Fri 25 Feb     , bbum@... wrote:
> Congratulations on the move to Subversion!   Very good, very good.  If 
> I had been paying attention, I would have volunteered to help as I 
> moved a few repositories-- including PyObjC-- over the past year.  If
> you need any assistance with configuration, let me know.

I might need some help with this. I'm having a real issue with merging
existing repositories. The problem is that there doesn't seem to be any
means of merging data while keeping the revision history. svnadmin import
replaces the target repositories data, and svnadmin load can't
arbitrarily apply the transaction entries to an existing repository. So
it looks like all I can do is pick one repository to keep the history
one by starting with it and then useing svn add to include the folders
from the other projects.

> In any case, I would highly recommend using the FsFs backing store for 
> Subversion.    It tends to be a lot less fragile and is the backend 
> being used by the subversion developers, these days.

From what I understand BerkleyDB is a good embedded database, but I did
run into issues when moving data files from one system to another.
running svnadmin dump is a must.

> Unless it has changed recently, you'll need to do the cvs2svn 
> conversion which will produce a Berkeley DB backed repository, then 
> dump the subversion repository, and then load it into an FsFs backed 
> repository.   A couple of extra commands, but worthwhile.
> 
> b.bum

Does anyone else care what format is used for the back end?

I'm currently trying to merge the other projects onto the converted
Webware cvs tree. It's taking a long time; the Webware tree took more
than 2-1/2 hours to convert. I'd hate to see how long a large repository
would take!

-- 
Eric Radman  |  http://eradman.com

bbum@... wrote:
> Congratulations on the move to Subversion!   Very good, very good.  If I 
> had been paying attention, I would have volunteered to help as I moved a 
> few repositories-- including PyObjC-- over the past year.   If you need 
> any assistance with configuration, let me know.
> 
> In any case, I would highly recommend using the FsFs backing store for 
> Subversion.    It tends to be a lot less fragile and is the backend 
> being used by the subversion developers, these days.
> 
> Unless it has changed recently, you'll need to do the cvs2svn conversion 
> which will produce a Berkeley DB backed repository, then dump the 
> subversion repository, and then load it into an FsFs backed 
> repository.   A couple of extra commands, but worthwhile.

Maybe you can help with an issue we're having -- is there anyway to 
merge repositories?  We already have stuff in the svn repository that 
we'd like to keep, as well as adding the Webware repository -- right now 
it looks like we'll have to create a new repository for Webware, then 
copy over all the stuff in the current repository (losing history), or 
maybe dump the current repository and put it in a sub-tree... hmm; I 
guess that would work in this case.

I did encounter a problem when I wanted to move WSGIKit over to the 
Webware repository, since I wanted to move one subtree into another 
subtree -- I ended up just copying everything over losing history for that.

-- 
Ian Bicking  /  ianb@...  /  http://blog.ianbicking.org

Eric Radman wrote:
>>In any case, I would highly recommend using the FsFs backing store for 
>>Subversion.    It tends to be a lot less fragile and is the backend 
>>being used by the subversion developers, these days.
> 
> 
>>From what I understand BerkleyDB is a good embedded database, but I did
> run into issues when moving data files from one system to another.
> running svnadmin dump is a must.

I've found bdb to be fragile on the backend; processes that only read 
from the repository (like viewcvs) still have to have write access, and 
there's locking and permission problems that result.  So using an fs 
backend would be nicer; though that conversion doesn't necessarily have 
to happen at the same time as the import.

-- 
Ian Bicking  /  ianb@...  /  http://blog.ianbicking.org