> > fossil import git > fossil import svn > fossil import hg > > And so forth.... Thoughts? >
If the format of the input stream can be auto-detected, then it can simply be "fossil import" can't it? You'll only need to specify format explicitly for the export I think. Q1: Rgd git import - my repo has git-svn branch references of the form >> "svnroot/BranchName". These have now been imported into fossil as >> branches with name "BranchName". Is the "svnroot/" info preserved >> somewhere in the repo? >> > > I was not real clear what should be done with those tags, so I stripped off > all but the last component of the tag. Is that not the right thing to do? > Please explain.... > Oh! In my case, the git branches named "BranchName" were tracking the branches named "svnroot/BranchName" and so I didn't have a problem, but in the general case I can imagine a collision if you just use the last term. As long as both branches are pointing to the same commit, there is no collision issue and you can drop one, but if they aren't then it'll help if the full branch name is retained - like "svnroot/BranchName" itself. So, ok, "fossil->git" is not an exact inverse of "git->fossil". SQLite has a great full-text search engine built in. I've long thought that > it would be great to add an interface to this in Fossil. We could index > diffs for all check-ins, all wiki, all tickets, all Blog entries, etc, and > then have a Google-like interface for searching for things. Of course, the > full text index would likely double the size of the repository file, but in > this era of TB-size disk drives, is that really an issue? > Such a search interface would be awesome! I don't think the size increase is an issue at all. The only case may be backups, but even they can be done using cloning - that would mean that the search index shouldn't sync. Cheers, -Kumar
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users