Return to tech-repository.mdwn CVS log

Up to [NetBSD Developer Wiki] / wikisrc / mailing-lists

Describe my experience with Fossil.

    1: ## Requirements
    2: 
    3: A list of requirements for a possible replacement for CVS as repo software for NetBSD and pkgsrc so we don't keep starting over listing these (and forgetting half) all of the time:
    4: 
    5: - the license would be nice to be BSDish, must be open source and free to use
    6: - the software should be includeable in NetBSD base without too much excess baggage
    7: - it should be possible to do development on old or small hardware
    8: - it must support automated updating of source trees
    9: - it must support branches
   10: - there should be a conversion for the present history (that actually works)
   11: - the resulting repository must not break easily
   12: - the software should be reasonably mature and reliable
   13: - checkout of a pkgsrc tree must be feasible on a 32MB system
   14: - checkout of a stable pkgsrc tree and then updating select package subdirs to the latest version of the main branch should be possible
   15: - lasting removal of legally tainted code must be possible
   16: 
   17: Please add/correct.
   18: 
   19: ***
   20: 
   21: ## Experiences in using the software
   22: 
   23: ### Experiences with Fossil
   24: 
   25: #### Aleksej Saushev (asau)
   26: 
   27: I started using it before conversion tool were available
   28: (basically it isn't available yet, to my knowledge Joerg is working on it),
   29: in addition I wanted to start as soon as possible
   30: and to try operation with no conversion tool available.
   31: Thus I've tried to simulate working with "vendor branches".
   32: 
   33: For now Fossil lacks some essential features and has other severe problems:
   34: 1. No support for vendor branches.
   35: 1. It is impossible to merge between trees growing from the very root.
   36: The initial commit is too special, this prevents using these trees for vendor branches.
   37: 1. There's no support for importing vendor source,
   38: even "addremove" command isn't in trunk at the time of writing.
   39: 1. Merge state sticks. You can't undo it.
   40: 1. You can't amend your source when you've just merged, you are forced to commit after merge.
   41: 1. You can't tune diff command to ignore RCS keywords.
   42: 1. You can't diff single file between two given versions.
   43: 1. There's no way to change commit messages.
   44: 1. There's no documented way to select commit messages of current branch, or branch by given commit id.
   45: Or there's a bug preventing it.
   46: 1. Commands are underdocumented, usage messages don't list many available options.
   47: This applies to trunk at least, there's a branch that states documentation as its goal.
   48: 1. There's no convenient way to look at commit contents: files affected, diff.
   49: 
   50: Some of above problems are reported.
   51: 
   52: Note, all problems above are usability problems, I didn't explore e.g. scalability,
   53: Joerg did and had problems, but this is another story.
   54: 
   55: ### Experiences with git
   56: 
   57: please fill in
   58: 
   59: ### Experiences with Subversion
   60: 
   61: please fill in
   62: 
   63: ### Experiences with Bazaar
   64: 
   65: #### Jonathan Perkin (sketch)
   66: 
   67: We use bzr at work (MySQL), and while it has a number of problems, it does make dev work easy.
   68: 
   69: The Good
   70: 
   71: * easy to use
   72: * shared repositories keep local disk usage down
   73: * commercial backing (Canonical)
   74: * cross-platform (works on Windows)
   75: * numerous GUI available
   76: 
   77: The Bad:
   78: 
   79: * slow
   80: * requires python
   81: 
   82: The Ugly:
   83: 
   84: * can be really slow
   85: * changing repository formats is a hassle
   86: 
   87: A basic example workflow
   88: 
   89: <pre>
   90: # create a local shared repository. all objects are held in a .bzr sub-directory, with branches essentially a lightweight checkout
   91: $ bzr init-repo bzr
   92: $ cd bzr
   93: 
   94: # fetch HEAD, will take a long time, depending on connectivity
   95: $ bzr branch bzr+ssh://bzr.netbsd.org/netbsd-trunk
   96: 
   97: # fetch netbsd-5, as we already have the majority of the code in netbsd-trunk (and therefore .bzr), this takes a fraction of the time
   98: $ bzr branch bzr+ssh://bzr.netbsd.org//netbsd-5
   99: 
  100: # ok, let's do some dev work
  101: $ bzr branch netbsd-trunk netbsd-trunk-sketch-fix-msk
  102: $ cd netbsd-trunk-sketch-fix-msk; hack hack hack
  103: 
  104: # the usual cycle of hack/commit/merge
  105: $ bzr diff # show uncommitted diffs
  106: $ bzr commit # commit to local clone
  107: $ bzr merge ../netbsd-trunk # update clone to latest local trunk, OR
  108: $ bzr merge bzr+ssh://bzr.netbsd.org/netbsd-trunk # merge directly from upstream
  109: 
  110: # publish our tree for others to review/hack on
  111: $ bzr push bzr+ssh://bzr.netbsd.org/netbsd-trunk-fix-msk
  112: 
  113: # got reviewed/tested, let's push it
  114: $ bzr merge bzr+ssh://bzr.netbsd.org/netbsd-trunk
  115: $ bzr missing bzr+ssh://bzr.netbsd.org/netbsd-trunk # show changeset differences
  116: $ bzr push bzr+ssh://bzr.netbsd.org/netbsd-trunk
  117: </pre>
  118: 
  119: I personally find this approach a lot more natural than git's way of managing branches itself inside a single working directory.
  120: 
  121: ***
  122: 
  123: ## Conversion experiences
  124: 
  125: ### git
  126: 
  127: Conversion of all modules to git succeeded using fromcvs togit. The resulting git repository of src contains several errors where files have a wrong version (eg in hunt/Makefile the contents of the file on the vendor branch appear as tip of the master branch, which is quite wrong).
  128: There have been no reports of errors in the other modules; this may be due to a lack of testing.
  129: 
  130: ### hg
  131: 
  132: Conversion of src failed. Afair the rest worked when using Mercurial 1.3.*. Alas, fromcvs tohg is not compatible with Mercurial 1.4 which is in pkgsrc now and is the version to use with Python 2.6 (afair). Two identified problems:
  133: <pre>
  134:         self.ui = ui.ui(interactive = False)
  135: </pre>
  136: wants to be
  137: <pre>
  138:         self.ui = ui.ui()
  139:         self.ui.setconfig('ui', 'interactive', 'off')
  140: </pre>
  141: in /usr/pkg/share/fromcvs/tohg.py line 10 (easily fixed, obviously)
  142: and
  143: <pre>
  144:         n = self.hgrepo.commit(files = files,
  145:                                text = text,
  146:                                user = user,
  147:                                date = "%s 0" % date,
  148:                                p1 = p1,
  149:                                p2 = p2,
  150:                                extra = {'branch': branch})
  151: </pre>
  152: needs to be replaces with something that works with the 1.4 commit that looks like this:
  153: <pre>
  154:     def commit(self, text="", user=None, date=None, match=None, force=False,
  155:                editor=False, extra={}):
  156: </pre>
  157: which is where I remembered that I wasn't planning to learn Python this week.
  158: 
  159: Next try: hg convert on pkgsrc
  160: <pre>
  161: --- /usr/pkg/lib/python2.6/site-packages/hgext/convert/cvsps.py 2009-12-02 01:30:45.000000000 +0000
  162: +++ /tmp/cvsps.py       2010-01-20 12:52:11.000000000 +0000
  163: @@ -271,14 +271,14 @@
  164:                  tags[rev].append(match.group(1))
  165:                  branchmap[match.group(1)] = match.group(2)
  166:  
  167: -            elif re_31.match(line):
  168: +            elif re_31.match(line) and re_50.match(peek):
  169:                  state = 5
  170:              elif re_32.match(line):
  171:                  state = 0
  172:  
  173:          elif state == 4:
  174:              # expecting '------' separator before first revision
  175: -            if re_31.match(line):
  176: +            if re_31.match(line) and re_50.match(peek):
  177:                  state = 5
  178:              else:
  179:                  assert not re_32.match(line), _('must have at least '
  180: @@ -357,7 +357,7 @@
  181:  
  182:          elif state == 8:
  183:              # store commit log message
  184: -            if re_31.match(line):
  185: +            if re_31.match(line) and re_50.match(peek):
  186:                  state = 5
  187:                  store = True
  188:              elif re_32.match(line):
  189: </pre>
  190: helps it to cope with the output of cvs rlog -N -r1.66 pkgsrc/databases/rrdtool/Makefile (that's the easy one)
  191: but then it tries to parse the output of (eg) cvs rlog -N -r1.19 pkgsrc/graphics/dcraw/Makefile and it's not clear
  192: to me how it could hope to get that one right just from cvs rlog, and all alternatives are going to be rather tedious
  193: and I'm still not planning to learn Python this week. If you feel more energetic, feel free to hand over patches.