On 2007-11-09 11:23, Julian Elischer wrote:
> ok having done this for years here's how it goes. If you have a
> private CVS repo mirroring the FreeBSD tree then you can keep your
> changes up to date in your "checked out" source tree. but you can
> generally not check them in anywhere.
> You CAN keep your own special branch (I think it was branch numbers
> above 100000 or something, check cvsup docs) that cvsup will not over
> write, and you can check in your changes there but that branch will
> not automatically update from freebsd.org so you will need to do
> branch updates regularly. (and that can be tricky and time consuming
> in CVS) otherwise your branch will get out-of date when compaerd with
> -current.
> usually I just keep my work checked out until I'm ready to feed the
> changes back but I take regular diffs and stash them away as 'backups' :-)
> This is why we have the perforce repo in addition to CVS. it is good
> at doing large branch manipulations, and it is more feasible to keep
> your own branch in sync with the branch that is kept up to date with
> the CVS tree.
> Unfortunatly, we don't give out access to that to 'anybody', it may be
> possible to get mercurial to do similar, or if you could get a
> 'personal use' p4 server you could get the scripts from Peter and see
> if you could do the same.

Git or Mercurial can track 'vendor' imports quite fine. There are tools
out there which can do either:

* Periodic 'imports' of the FreeBSD src/ tree as 'vendor' code

* Incremental conversion of /home/ncvs/src in 'changesets'

I've been using a 'converted' tree for almost a year and a half now, to
keep a local mirror of the src repository at `/ws/freebsd/head' on my
laptop. The first clean import of the current tree I am using was done
during last summer:

changeset: 0:98902a1e0339
user: ncvs
date: Mon Jul 16 17:03:48 2007 +0000
summary: Import FreeBSD src/ snapshot at 2007/07/16 17:03:48 +0000

Now I'm up to and including the following src commit:

changeset: 1361:0362088cd690
tag: tip
user: brueffer
date: Tue Nov 13 16:42:22 2007 +0000
summary: Xref wpi(4).

Then, in a clone of this, I keep a local "patch queue", which is rebased
on top of the 'vendor' clone of src/, with several changes which are not
yet ready to hit src/:

keramida@kobe:/wd/bsd/src$ hg qseries -s
regression-tr: Add some regression tests for the tr(1) utility
du-hardlinks: Add a -l option to du(1), to allow counting hard links multiple times
yacc-ruslan: Fix a yacc(1) core dump reported by darrenr; patch by ru
snd-emu10kx: Various mdoc style and wording fixes.
loader-prompt: Lowercase the "OK" boot loader prompt
top-wcpu: make *top* use raw (non-weighted) cpu mode by default
ffs-fsync-typo: Minor typo nit in ffs_fsync()
kernconf-kobe: Add KOBE kernel config file, for my laptop

My own preference, as shown by the hg(1) utility above is to locally use
Mercurial, so if anyone wants help in setting up a 'clone' of the src/
repository, I can help with the setup details.

I don't have a fast enough connection to keep online a mirror of the
src/ repository myself, but maybe someone else can help with that.
Then, 'anybody' can clone the workspace and keep 'pulling' from it :-)

> I wonder if ther is a way we could broadcast changes to the p4 'head'
> branch so that people could keep their own p4 servers up to date.

Unfortunately, no. Perforce is not easy to 'mirror' around the world,
but it's ok. For a determined person, it should be fairly easy to set
up a local mirror of any part of the FreeBSD src tree, using one of
the distributed SCMs. They have *great* support for mirroring clones
of the original repository, and most of them have fairly good support
for incremental updates over the wire --- transferring the minimal
number of bits and bytes over a slow connection, they can keep an up to
date local clone of a remote tree.

I don't know of anything which can do the same for Perforce depots;
which is unlucky, because it would help me *tremendously* in my every
day ${realjob} too. If anyone wants help with setting up Mercurial to
do something like this, however, I'm all for it and I will help in any
way I can.

- Giorgos

freebsd-hackers@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"