I think it is a great idea to implement these things!
forking a project is easy (every "cp -r ..." is a fork from my point of view),
but merging can be hard, depending on the tools you use.
thus my advice:
a) stay in opensc svn, but simply do
svn cp https://..../svn/opensc/trunk \
https://..../svn/opensc/branches/some-name
and then from time to time merge the changes that happend in the mean time
in trunk into your branch, until your branch is ready to be merged back
into trunk.
with old subversion you would need to keep manual notes of the revision
where you copy svn trunk to your branch, and then everytime you
"merge trunk" you more or less tell svn to diff from that revision to
the current trunk revision, and apply that patch on top of your current
branch. then you need to write down the new current revision of trunk
used in this "merge" as reference for the next "merge". newer subversion
should be much improved over this note-keeping process, but I haven't
worked with it so far.
b) use git/hg/bazar with svn bridge to import current opensc repository
and all future changes to it, and develop in git/hg/bazaar. you can
publish your codebase on one of the popular hosts (github, launchpad,
the mercurial hub whose name I don't remember right now), or on
opensc-projects.org (I guess, pending martins approval) - only a small
admin work needed to add some ssh account for you with write access
in /var/www/some-name
Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
