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
keramida@kobe:/ws/bsd/src$

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
http://lists.freebsd.org/mailman/lis...reebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis...reebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"