¿Cómo almaceno en subversión mis personalizaciones en un proyecto público de código abierto?

Estoy trabajando en la personalización de un par de proyectos de código abierto de una manera muy personalizada, es decir, no apropiada para enviar los parches a los mantenedores para el público. Uno de ellos está almacenado en CVS, uno en SVN. Yo uso SVN para mi propio trabajo.

El proyecto CVS está bien. Compruebo el tree en mi repository svn, incluidos los directorys CVS. Puedo enviar todos mis cambios y aún hacer una actualización de cvs para estar al día con las correcciones de errores / características del proyecto público.

¿Cómo debería trabajar en el proyecto svn? ¿Existe una 'mejor práctica' o procedimiento conocido para este tipo de escenario?

Eche un vistazo a la sección en la documentation sobre sucursales de proveedores .

El proyecto cvs funciona desde que lo pones bajo control de versiones (en svn ). ¿Por qué no puedes poner el repository svn bajo el control de la versión ( svn ) también? ¿Puedes con twigs de proveedores como las sugeridas por Michael?

Si la respuesta es "porque está desorderada y no se ve bien", se dio count de las limitaciones (estéticas) del control de versión no distribuida. Sugiero que investigue qué sistemas de control de versiones distribuidas (DVCS) como git , mercurial o bzr pueden ofrecerle. Descubrirá que, por ejemplo, git hará que sea muy fácil mantener su parche en la parte superior del repository aguas arriba. Solo mantendría una twig privada del código, usando, por ejemplo, git rebase para reenviar los cambios. Todos estos DVCS vienen con algunas forms de interactuar con cvs ascendentes o repositorys svn .