4

Any recommendations on improvements to my approach for migration away from Veracity?

Background:

I finally hit my limit with Veracity:

  1. all attempted commits (after 6 months of use) suddenly give "Error 101 (sqlite): sg_wc_db:tbl_gid can't find alias 7033." (I searched - couldn't find help on this anywhere).
  2. Veracity 2.5 (the latest version) is over 4.5 years old at the time of this latest edit.
  3. "Questions" link at http://veracity-scm.com/qa (which was formerly useful) now gives a 404 simply redirects back to the home page.
  4. The online community surrounding Veracity seems too small, and http://sourcegear.com/ seems focused on its non-open source version control systems, instead.

In summary, I've lost confidence in Veracity to manage my significant bits.

Extraction Approach I Used (admittedly low-tech):

  1. used "vv fast-export" to get a fast-import stream for my new DVCS. This preserved the source history.
  2. Manually copied out my Veracity wiki pages to another existing wiki I use.
  3. (Most tediously) Pored over my Veracity Work Items to make sure I didn't lose information critical to my project.

Conclusion:

I was originally seduced by the integrated wiki & bug tracking features of Veracity. I now regret that choice, and have moved back to a more mainstream DVCS option.

dave_k_smith
  • 485
  • 1
  • 6
  • 17
  • 3
    Yes, I tried to use it yesterday, and it doesn't work on El Capitan. Seems like a good abandoned project. – vr_driver Apr 19 '16 at 00:00

1 Answers1

3

I've used fossil (http://fossil-scm.org) for at one small project.

It's a little different from almost everything else it seems. That said I would still classify it as developer-friendly. The biggest issue I found when I evaluated it was that it did not have mature ide-integration at that time.

Erik I
  • 852
  • 1
  • 11
  • 27