Re: [VuFind-Tech] local SVN project setup

[Naomi D. <nd...@st...>]

Well, I got a query about my post, so I've decided to go ahead and  
post this to the list.

1.  Externals model

The externals model I was looking at:

http://www.ghidinelli.com/2007/10/12/managing-third-party-software-with-subversion/

the author says, in a comment at the very bottom: "Mike’s trackback  
had a good link to the SVN book that talks about “Vendor Branches” as  
an alternate solution to what I’ve proposed above. One aspect it  
discusses that I haven’t dealt with yet is making code changes to the  
3rd party release and maintaining those changes across revisions."

d'oh!

which basically implies vendor branches are the best model.  Given  
that I've looked at stuff on the web, and poured over 3 books about  
subversion source control, and everything says "vendor branch model",  
I'm guessing it's the most elegant solution people have thought of to  
date.

2. Vendor branch model
http://svnbook.red-bean.com/en/1.4/svn.advanced.vendorbr.html

What I've seen about the conflict resolution is that it's a pain, but  
people have worked on improving it.  Various references:
1. http://subversion.tigris.org/faq.html#vendor-branch
2. Piston   http://piston.rubyforge.org/
2a.  i confess i'm loathe to add yet another new unknown tool into the  
mix!  But it's supposed to be pretty good, and I will look it over.
3. svn_load_dirs.pl
3a. potentially helpful blog entry:  http://burtonini.com/blog/computers/svn-vendor-2005-05-04-13-55
4. svk   "I find svk's import much better(and faster) than  
svn_load_dirs. It use the same subversion repository and don't need to  
checkout a working copy when doing the import." - comment to burtonini  
blog post
4a.  svk - a decentralized version control system based on subversion  http://svk.elixus.org/
4b.  I will look at it a little more.

Nothing's perfect, I guess.   To be honest, this whole source control  
setup has been driving me crazy, and I just want to be done with it.

- Naomi

> On Jun 16, 2008, at 8:39 AM, Naomi Dushay wrote:
>
>> Is there an elegant way for us to have a local instance of VuFind
>> code, with our local mods AND have an easy way to incorporate new
>> releases of the open source VuFind project  as well as changes to
>> the trunk of the open source VuFind project?
>>
>> I know how to do this for a project in a compiled language like java
>> - you ensure that your locally modified compiled files are in the
>> classpath ahead of the vanilla compiled files.  I haven't found a
>> way to mimic the classpath ordering for interpreted languages like
>> PHP and Ruby.
>>
>> I've read up on Externals Definitions, and I've read up on Vendor
>> Branch models.  It seems that there are painful pieces to all the
>> models I've encountered.
>>
>> Vendor Branch models:  when the vendor software is upgraded, you
>> have some tricky work to do dealing with files in the old release
>> that have been deleted in the new release.  I haven't tried the
>> svn_load_dirs.pl script, but it's
>