on Tue May 21 2013, Vladimir Prus
On 20.05.2013 10:08, Dave Abrahams wrote:
I would be fine with /dev/null, to be honest, unless Rene and Steven have any concerns. That is part of the history that is either not used at all, or has been rewritten over and over, so it won't be much useful in future.
You're free to delete any branches you want after the conversion is over (it's really easy), but until then, we want to make sure every commit is accounted for. Any commits that aren't caught by the ruleset end up in https://github.com/boostorg/svn2git-fallback and the build at http://jenkins.boost.org fails.
You can make an arbitrarily obscure branch name (e.g. old-branches/deleteme) and send unwanted history there, if you like. Please try to submit a pull request with edits to repositories.txt. An explanation of the semantics is at: https://github.com/ryppl/Boost2Git/wiki/Editing-repositories.txt
Dave,
I have spent around 30 minutes trying to grok this format, and I cannot quite figure how how to sent tools/build/v2 directory to master branch of "build" repo, while sending everything else from trunk/tools/build into some other branch.
That doesn't sound like a very accurate reflection of history. There used to be code in tools/build/, directly. What "other branch" should that go into, and at what path would you like it to be placed? And there are lots of changes outside trunk/ that should get similar treatment, whatever you decide to do. See: https://github.com/boostorg/build/branches https://github.com/boostorg/build/tags One possibility is that you keep everything under tools/build (other than tools/build/v2) in the branches where it currently resides, but put it in a subdirectory called v1/ rather than at the top level. However, there's probably a point in history where that stuff would *belong* at the top level because, e.g., v2 didn't exist.
If the change is easy, as you make it sound, can either you or Daniel make it?
We could... but I am a little concerned about making changes to history that diverge too far from reality. Remember, you are free to move things around and rename branches after modularization is complete... but I'm not sure we should do too much revision of the actual history. Thoughts? -- Dave Abrahams