local SVN project setup - please help

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

local SVN project setup - please help

Naomi Dushay
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




Naomi Dushay
[hidden email]




-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: local SVN project setup - please help

Naomi Dushay
This went out by mistake.  I'm set with this.

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
>
>
>
>
> Naomi Dushay
> [hidden email]
>
>
>

Naomi Dushay
[hidden email]




-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: local SVN project setup

Naomi Dushay
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
>






-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: local SVN project setup

Mark Triggs-2
Hi Naomi,

We originally tried vendor branches when tracking from VuFind 0.6, but
our reading at the time suggested that it was almost like working
outside of Subversion--using extra contrib programs to handle the messy
process of merging changes etc..

At the moment I've been thinking about seeing what Git and its
Subversion integration can do for us.  For our internal development we
have a Subversion repository that holds the "master" copy of our source,
but Steve and I both use Git for our day-to-day development.  We've
found it really good because it means we can hack what needs hacking in
the Git repositories, then clean up our working history, write sensible
logs and push our nice clean changes back into our svn repo using
git-svn.  I'm hoping that similar magic is possible when tracking
changes to a remote svn repository too :o)

At any rate, I'll post back to the list if we strike on anything
particularly amazing.

Cheers,

Mark


Naomi Dushay <[hidden email]> writes:

> 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.

--
Mark Triggs
Systems Administrator
Business Systems Support, The National Library of Australia
<[hidden email]>

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: local SVN project setup - please help

Andrew Nagy-2
In reply to this post by Naomi Dushay
Can you share with others how you are managing your local modifications?

Thanks
Andrew

> -----Original Message-----
> From: [hidden email] [mailto:vufind-tech-
> [hidden email]] On Behalf Of Naomi Dushay
> Sent: Monday, June 16, 2008 1:05 PM
> To: [hidden email]
> Subject: Re: [VuFind-Tech] local SVN project setup - please help
>
> This went out by mistake.  I'm set with this.
>
> 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
> >
> >
> >
> >
> > Naomi Dushay
> > [hidden email]
> >
> >
> >
>
> Naomi Dushay
> [hidden email]
>
>
>
>
> -----------------------------------------------------------------------
> --
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Vufind-tech mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vufind-tech

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: local SVN project setup - please help

Alan Rykhus
Hello Andrew,

Since I just finished getting synched up with revision 700 I'll relate
how I do it.

I have 3 separate installations.

1) Is a copy of the default installation that I run 'svn update' to get
the latest revisions.

2) Is a copy of the default installation that is at the same revision as
my local code that I'm working with.

3) Is my local customized version.

I do a diff between 1 and 2. If I have not customized the particular
file I can copy it directly to my customized version. If I have
customized the file I crawl through the changes and apply them to my
customized file. When I finish updating a particular file I then update
the file in 2) so that it will not show up the next time I do a diff.
While it is a little painful, its no worse than maintaining updates to
our ILS.

al

On Tue, 2008-06-24 at 11:31 -0500, Andrew Nagy wrote:

> Can you share with others how you are managing your local modifications?
>
> Thanks
> Andrew
>
> > -----Original Message-----
> > From: [hidden email] [mailto:vufind-tech-
> > [hidden email]] On Behalf Of Naomi Dushay
> > Sent: Monday, June 16, 2008 1:05 PM
> > To: [hidden email]
> > Subject: Re: [VuFind-Tech] local SVN project setup - please help
> >
> > This went out by mistake.  I'm set with this.
> >
> > 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
> > >
> > >
> > >
> > >
> > > Naomi Dushay
> > > [hidden email]
> > >
> > >
> > >
> >
> > Naomi Dushay
> > [hidden email]
> >
> >
> >
> >
> > -----------------------------------------------------------------------
> > --
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://sourceforge.net/services/buy/index.php
> > _______________________________________________
> > Vufind-tech mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/vufind-tech
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Vufind-tech mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vufind-tech
--
Alan Rykhus
PALS, A Program of the Minnesota State Colleges and Universities
(507)389-1975
[hidden email]


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: local SVN project setup - please help

Naomi Dushay
In reply to this post by Andrew Nagy-2
We're using the "Vendor Branch" model.   There is an excellent  
explanation here:

http://svnbook.red-bean.com/en/1.4/svn.advanced.vendorbr.html

I expect my attempt to summarize below will confuse more than  
illuminate, so feel free to stop reading and check the above ref.  The  
"vendor branch" model has been around for a while, so there are plenty  
of other explanations and references out there.

Basically, there is a "vendor" branch in the repos for the "default  
installation" that itself has a sort of trunk, called "current", and a  
"tags" branch.  I explicitly pull the default version from the  
external SVN repos and update my "vendor/current" branch.  Then I  
create a locally tagged version, e.g. vendor/tags/VUFIND_RL_357.  I do  
local development on the regular (non-vendor) "trunk" branch.  This  
set up allows me to merge changes between two locally tagged vendor  
versions to my local development -- that is, I can do an SVN merge,  
applying the latest vendor mods to my local development ... and I can  
control when I'm pulling which vendor updates.

svn / trunk    <-- current local development
svn / tags    <--  tagged local development
svn / vendor / current  <-- "current" default code  (I determine what  
"current" means - I do an explicit pull)
svn / vendor / tags <-- locally tagged default code.

The main difficulty with this model is after you pull new "vendor"  
code -- it can be tricky to figure out if a file has been deleted or  
moved since the last pull.  SVN provides a perl script to help with  
this, but I hear it's not great.  I've only done the first pull so  
far, since we just set up an SVN repository so I could work more  
easily with external SVN projects.

I believe git is a newer source control tool that copes with the above  
better, and it's also supposed to work well with svn repositories.  
But we postponed investigating this further.  Perhaps later in the  
fall ...

- Naomi

On Jun 24, 2008, at 9:31 AM, Andrew Nagy wrote:

> Can you share with others how you are managing your local  
> modifications?
>
> Thanks
> Andrew
>
>> -----Original Message-----
>> From: [hidden email] [mailto:vufind-tech-
>> [hidden email]] On Behalf Of Naomi Dushay
>> Sent: Monday, June 16, 2008 1:05 PM
>> To: [hidden email]
>> Subject: Re: [VuFind-Tech] local SVN project setup - please help
>>
>> This went out by mistake.  I'm set with this.
>>
>> 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
>>>
>>>
>>>
>>>
>>> Naomi Dushay
>>> [hidden email]
>>>
>>>
>>>
>>
>> Naomi Dushay
>> [hidden email]
>>
>>
>>
>>
>> -----------------------------------------------------------------------
>> --
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> Vufind-tech mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/vufind-tech

Naomi Dushay
[hidden email]




-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: local SVN project setup - please help

Barnett, Jeffrey
Naomi, I'm trying to follow this model, but I get hung up with your term "pull".  Is this equivalent to "svn export" (from sourceforge/svn/vufind), or is there a special meaning I'm unaware of?

You also say you've heard that the svn script (I'm assuming svn_load_dirs.pl) is "not very good".  I notice that mention of it in the svn lists seems to peter out around 2006.  Are there specific problems or is it just a personal preference to have more control of the process?  In any case, it doesn't seem to come with the standard (red hat) svn package.  Do you know of a current source if I wanted to try it out?

Have you done any "pulling" since this post?

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Naomi Dushay
Sent: Tuesday, June 24, 2008 11:54 PM
To: [hidden email]
Subject: Re: [VuFind-Tech] local SVN project setup - please help

We're using the "Vendor Branch" model.   There is an excellent
explanation here:

http://svnbook.red-bean.com/en/1.4/svn.advanced.vendorbr.html

I expect my attempt to summarize below will confuse more than
illuminate, so feel free to stop reading and check the above ref.  The
"vendor branch" model has been around for a while, so there are plenty
of other explanations and references out there.

Basically, there is a "vendor" branch in the repos for the "default
installation" that itself has a sort of trunk, called "current", and a
"tags" branch.  I explicitly pull the default version from the
external SVN repos and update my "vendor/current" branch.  Then I
create a locally tagged version, e.g. vendor/tags/VUFIND_RL_357.  I do
local development on the regular (non-vendor) "trunk" branch.  This
set up allows me to merge changes between two locally tagged vendor
versions to my local development -- that is, I can do an SVN merge,
applying the latest vendor mods to my local development ... and I can
control when I'm pulling which vendor updates.

svn / trunk    <-- current local development
svn / tags    <--  tagged local development
svn / vendor / current  <-- "current" default code  (I determine what
"current" means - I do an explicit pull)
svn / vendor / tags <-- locally tagged default code.

The main difficulty with this model is after you pull new "vendor"
code -- it can be tricky to figure out if a file has been deleted or
moved since the last pull.  SVN provides a perl script to help with
this, but I hear it's not great.  I've only done the first pull so
far, since we just set up an SVN repository so I could work more
easily with external SVN projects.

I believe git is a newer source control tool that copes with the above
better, and it's also supposed to work well with svn repositories.
But we postponed investigating this further.  Perhaps later in the
fall ...

- Naomi

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech