On 24.02.2012 19:34, Greg Ercolano wrote: > On 02/24/12 09:37, Albrecht Schlosser wrote: >> <OT> When we talked about moving to git[hub] as an option, I tried >> and succeeded converting the FLTK svn repository to git. It took me >> some tries (maybe not enough memory in the Linux VM), but finally it >> worked and looked correct. So this is an option, but I'm still waiting >> to see progress on the new server... >> </OT> > > Neat.. so I take it our old revision history could be preserved > when transferred to git? That's cool.
Yep. > Is it possible to use our old svn numbers when pulling things > out of git? We have so many conversations in newsgroups and STRs > referring to our svn#'s, so it's important they remain relevant. I'm by far not a git expert. In fact, I never used it myself, just tried to learn and do some experiments. That said, there is "git svn" that can be used to access a remote subversion repository, so that you can work with a local git repository. If you do this, then it seems that you can refer to the subversion revision numbers. There also seem to be some problems with committing changes, so I think this is not generally recommended for normal work. The original remote repository would stay in subversion format, and the local git repository stores meta data to map the subversion revision numbers. The other way is to convert a subversion repository to a git repository and use this. There is a description in "progit.pdf" that shows how to do it. The example command shown there is: $ git-svn clone http://my-project.googlecode.com/svn/ \ --authors-file=users.txt --no-metadata -s my_project The "--authors-file" option is used to convert subversion user names to git user names (and e-mail addresses), and the "--no-metadata" option is used to strip that subversion meta information mentioned above. I think that this should be used for a final conversion, so that there are no more subversion revisions available. :-( However, from the time of conversion (and upload to the new central server, be it fltk.org or github) there is little need for svn rev. numbers, since there won't be such numbers in the future. Then we'd have only the git commit numbers (hash values). > I'd hate to think we'd have to use those damned UUID hex strings > for rev#s in git; someone else brought that up a few weeks ago > Those magic hex strings of crap really bug me. I keep running > into them in unexpected places; Microsoft's new project files, > Apple's OS files, etc. > > I hate them because they're meaningless modem noise to humans, > so it's impossible just by looking at one to know if it's corrupted, > or to gain any insight when things are broken. > > They're basically magic strings of crap only computers can read. > It seems unix philosophy taught us to avoid such things > (keep everything ascii and human readable for debugging > purposes and to have OS files be self-evident). I'm afraid this would be so - *if* we switched to git. Albrecht _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
