fossil for NetBSD / pkgsrc ;)

[Jens Rehsack <sno%NetBSD.org@localhost>]

Am 14.07.2013 um 18:10 schrieb Martin Husemann <martin%duskware.de@localhost>:
> However, before we run and go with the most vocal crowd, we need a plan
> for each eligable VCS.
> 
> That plan needs to have:

Even if I cannot answer all things, let's do a start for fossil, to avoid
the list keeps empty :P

> - a documentation of changes to the workflow for developers, including
>   the typical commands to be used

I think, for the most common tools dh@ already did:
Am 14.07.2013 um 20:35 schrieb David Holland 
<dholland-developers%netbsd.org@localhost>:

>   cvs                     hg                      git
> 
>   cvs add patches
>   cvs add patches/patch-* hg add patches/patch-*  git add patches/patch-*
>   cvs -n update           hg status               git status
>   cvs diff -up            hg diff -p              git diff -p
>   cvs commit              hg commit               git commit -a
>                           hg push                 git push
> 
> It's really not different. Oh, and the case where a package no longer
> needs a particular patch:
> 
>   cvs                     hg                      git
> 
>   rm patches/patch-ab
>   cvs rm patches/patch-ab hg rm patches/patch-ab  git rm patches/patch-ab
>   cvs -n update           hg status               git status
>   cvs diff -up            hg diff -p              git diff -p
>   cvs commit              hg commit               git commit -a
>                           hg push                 git push

Well - might be polished here and there (track the answers …) and extended by

  fossil

  fossil add patches/patch-*
  fossil status
  fossil diff --brief
  fossil commit
  fossil push

I try to get a small talk for FrOSCon end of August showing how I do my
Perl5 package updates with fossil locally and later send them upstream.
Maybe that could complete the above list.

> - a dependency list including licenses and special hints (e.g. how to
>   configure git without perl), should we include it in base src

fossil requires readline, openssl libz and some kind of editor (I think,
our users would favor vi over ed).

> - a list of dependencies for the server setup

joerg@ should be able to help there detailed, 'cause he has some running.
From documentation I'd say, there is currently not more for fossil itself,
but for unified frontend we should setup an nginx proxy - or whatever fits
our needs (and can do the authentication for backend fossil …).

> - a sketch of a possible way to get the import of the repo done (might be
>   trivial with joerg's work already done)

/me points to joergs@ work there.

> - a rough memory or other limits analysis, giving us some assurance the
>   system will deal with a repo of our size

Since autumn 2011 I try to do my local work on pkgsrc using fossil bothering
joerg@ from time to time. In the meantime - most time because of upstream
issues in our cvs stuff - my repo grows up to nearly 6,5GB. The current export
is smaller (around 2GB) and it looks as if the most issues are fixed and
once migrated, no huge increase is expected.

I think, Joerg should be able to give us a ratio of metadata to payload.

> All of this should be posted to tech-repository. From this, a list of viable
> options can be created - and then we can have a vote.

I hope that helps to open a list of viable options. If requested, I can try
to do something similar for subversion (that should be a suitable backend for
git or fossil in front).

Cheers
-- 
Jens Rehsack
pkgsrc, Perl5
sno%NetBSD.org@localhost