git-svn and branches/upstream/{current,THE_REST}

Yaroslav Halchenko lists at onerussian.com
Tue Oct 16 04:50:51 UTC 2007


Hi Martin and The List,

Pardon my ignorance if it is just too late and I should go too sleep to
see something obvious tomorrow morning. Is there something I am missing
or git-svn approach of migration needs some additional tuning here? :-)

if we use git-svn to convert existing svn repository which used to be
created/used with svn-buildpackage, then directory branches/upstream
contains somewhat of a branch current/ (where svn kept rolling history
of injected and later on upgraded upstream releases) and tags
(such as X.Y.Z/) which are pretty much tags on top of "current" branch.

git-svn sure thing doesn't know about that, and I don't see any option
to it which would allow to provide such tessellation within
branches/upstream directory.

History when and why I discovered this issue for myself:

For my fail2ban package I managed to create initial gitization of svn
repository + added upstream-repo access via git-svn, but I couldn't use
tagged releases of upstream-repo/trunk since upstream's release tarballs
(which serve as .orig.tar.gz) are sanitized from the tagged version
in SVN (removed .project, expanded tags in CHANGELOG etc). That is
why I thought to create decent timeline of upstream source changes from
the history of upgrades within debian package upstream sources, but now
it boils down to somewhat manual procedure: svn-upgrade does 2 commits,
where 1st is upgrade of current and 2nd is actually tagging of that
current into X.Y.Z directory, so theoretically by following the history
of current/ I can reproduce my upstream branch.

-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
        101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW:     http://www.linkedin.com/in/yarik        



More information about the vcs-pkg-discuss mailing list