views:

21

answers:

2

Hi, I'm working on customizing a couple of open source projects in ways that are very much personalized -- i.e., not appropriate to send the patches back to the maintainers for the public. One of them is stored in CVS, one in SVN. I use SVN for my own work.

The CVS project is fine. I check the tree in to my svn repository, including the CVS directories. I can commit all my changes, and still do a cvs update to stay up to date with bug fixes/features of the public project.

How should I work on the svn project? Is there a 'best practice' or known procedure for this kind of scenario?

+1  A: 

Take a look at the section in the documentation on vendor branches.

Michael Hackner
Great -- I guess that I didn't know the definition of "Vendor Branch" until now :-)
Clyde
A: 

The cvs project works since you put it under version control (in svn). Why can't you put the svn repository under (svn) version control, too -- you can with vendor branches like suggested by Michael?

If the answer is "because it is messy and doesn't look right" you came to realize the (aesthetic) limitations of non-distributed version control. I would suggest you look into what distributed version control systems (DVCS) like git, mercurial or bzr can offer you. You will find out that e.g. git will make it very easy to maintain your patchset on top of the upstream repository. You would just maintain a private branch of the code, using e.g. git rebase to forward your changes. All these DVCS's come with some ways to interact with upstream cvs or svn repositories.

honk