Steven Grimm <koreth@xxxxxxxxxxxxx> wrote: > How about using git itself to keep some of this information? I'll just > throw this idea out there; might or might not make any actual sense. > > Create a new "git-svn metadata" branch. This branch contains a fake > directory (never intended for checkout, though you could do it) that > has a "file" for each svn revision. The filename is just the svn > revision number, maybe divided into subdirectories in case you want to > check the branch out for debugging purposes or whatever. The contents > are the git commit SHA1 and whatever other metadata you want to keep > in the future. > > The advantage of doing it this way? You can pass around svn metadata > using the normal git fetch/push tools, query the metadata using "git > show", etc. In terms of data integrity, it's as secure as anything > else in a git repository, much more so than a separately maintained db > file under .git. I've thought of doing the way you describe in the past, too. However, a missing ref to the tree you proposed would mean that the metadata becomes inaccessible unless git-svn-id: lines are retained. Right now there's a single ref for all data and metadata. Going to two refs would mean those two refs would always need to be in sync with each other. The basic idea of the git-svn-id: lines is that with the default settings, the .rev_db files are deletable and can be regenerated from that metadata. git-svn will automatically re-create .rev_db files it cannot find. This is why the rev_db code in git-svn uses slow, synchronous writes iff svk props or no-metadata is enabled; and fast, assynchronous writes when the user sticks with the git-svn defaults. > Along similar lines, a separate branch where the filenames are commit > SHA1s and the file contents are the stuff that currently gets written > into the git-svn-id: lines would mean no more need to rewrite history > when doing dcommit, and thus easier mixing of native git workflows and > interactions with an svn repository. The current dcommit still has the advantage that commit times match those in the SVN repository. > It would be great if you could clone a git-svn repository and then do > "git svn dcommit" from the clone, secure in the knowledge that things > will stay consistent even if the origin gets your changes via "git svn > fetch" rather than from you. It's actually doable after the [svn-remote "..."] section .git/config is copied and the refs/remotes/* structure is cloned via git. The [svn-remote "..."] information can be regenerated based on git-svn-id: lines (there's no automated way to do that, currently). -- Eric Wong - 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
