Hello All,
As far as I know, git-svn metadata is global to the repository. That
works well for common cases but begins to break down as soon as subtree
merges (and maybe submodules) are involved.
Here is the scheme I like to use:
- Many components, each with its own repository mirrored from svn
- One "project" repository that aggregates the components with subtree
merges (via git-subtree)
Typically I work on one or two components, making commits that I'd like
to dcommit back to svn. Because svn metadata is global I can't keep
metadata for each component in the project repository. Instead I have
to have this in my work area:
workarea
project
commit
component1
component2
component3
...
That is, I have a separate checked-out copy of each individual
component. Each of these repositories has the svn metadata for its
component.
Then when I'm ready to dcommit, I do something roughly like this in
the project repository:
- git subtree split --rejoin --branch=component1_commit
- git push <workarea/commit/component1> component1_commit
- cd workarea/commit/component1
- git svn fetch
- git checkout component1_commit
- git svn dcommit
What I'd rather do is this:
- git subtree split --rejoin --branch=component1_commit
- git checkout component1_commit
- git svn fetch # Keep metadata separate in this branch for any other
# metadata
- git svn dcommit
If we had metadata per branch I wouldn't have to keep around an entire
duplicate of all of the project source that only gets used as a vehicle
to dcommit. I would simply create a branch for each component and
populate it with its svn metadata.
Has there been any discussion about this model of operation for git-svn?
I imagine it would be a rather large change. I'd be willing to put some
time into implementing this if it sounds feasible.
Thanks!
-Dave
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html