Re: questions on development(7)
Hi, Sorry for the late reply. On Fri, Nov 09, 2007 at 04:56:24AM +, Aryeh M. Friedman wrote: 4. Mergemaster behaves strange now: everytime I run it does a buildworld before doing the merge (even if I just did a installworld)... also it seems to default this to /usr/src2 (which is most of the time what I want)... is this normal? and if so how do I turn it off and if I can't how do I set which source tree to use? This is because you're using -m /usr/src2 instead -m /usr/src2/etc. mergemaster(8) isn't well documented for this point. I've written a PR about this and Ruslan Ermilov pointed out he already submitted a better solution to this problem nearly two years ago. Mine: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/118536 Ruslan's: http://www.freebsd.org/cgi/query-pr.cgi?pr=96528 Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
On 2007-11-14 17:48, Daniel O'Connor [EMAIL PROTECTED] wrote: 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: I have seen a few Hg repos although I haven't found one for RELENG_7 [yet]. I'm only tracking 'HEAD' most of the time, but there are some efforts underway to convert the history of src/. One notable example is the effort to convert to Subversion first, and then use the tags/branches and changesets of Subversion to populate an Hg tree. Also cvs20hg doesn't appear to grok Hg branches (probably because it predates them) and it would be Really Nice(tm) if it did. Both true. But we are off in a tangent. If you have interesting bits about Hg or other dSCMs, please contact me off-list or help us keep the wiki pages about Version Control up to date. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
On 2007-11-14 15:31, OutbackDingo [EMAIL PROTECTED] wrote: All ive seen in FreeBSD hg branches is a current and a releng_6 Id like to see a complete tree converted if there is one out there. I do have some bandwidth to potentially host such a conversion for others. question is does one exist ? Not until we *do* a conversion. There are many interesting points to consider, when planning this sort of conversion, though. For example, converting the *entire* history of the src/ tree may create workspace metadata files up to 400-500 MB. Do we *really* want to keep all of this in Hg, or is it sufficient to import a 'flag day' snapshot in Hg and incrementally update that from the commits to CVS? If you are interested in this sort of thing, please email me privately, or let's start a thread in *one* list about conversions and what we aim for. An even better idea would be for people who are interested to go through the web pages at: http://wiki.freebsd.org/VersionControl and then email me or one of the developers who have edited these pages, so we can keep updating the information there. PS: Cross-posting to two lists (current and hackers), somehow doesn't feel right. Can we at least drop -current please? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
[cc cleaned, dropped -current] Giorgos Keramidas wrote: I'm only tracking 'HEAD' most of the time, but there are some efforts underway to convert the history of src/. One notable example is the effort to convert to Subversion first, and then use the tags/branches and changesets of Subversion to populate an Hg tree. That seems wrong. A conversion to subversion means losing precision and time. Also cvs20hg doesn't appear to grok Hg branches (probably because it predates them) and it would be Really Nice(tm) if it did. cvs20hg is deprecated since two years or so. Please try fromcvs instead. There are some bugs left, of course. Last thing it seems I introduced some memory overflow problem, so that a conversion of src now runs out of memory (on a 32bit machine). Up to a couple of months ago this was running very smoothly, see [1]. However I don't think that using named branches in hg is a nice or elegant thing anyways. But that's OT, of course. Both true. But we are off in a tangent. If you have interesting bits about Hg or other dSCMs, please contact me off-list or help us keep the wiki pages about Version Control up to date. I suppose you know about fromcvs. I also guess you know that I suggest using git instead of hg. Doesn't produce nasty large index files either :) cheers simon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
I suppose you know about fromcvs. I also guess you know that I suggest using git instead of hg. Doesn't produce nasty large index files either :) cheers simon So would you think cvs - git - hg might be easier to accomplish ?? Since one of my goals is to update projects Ive done based on FreeBSD that require OS level updating ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
OutbackDingo wrote: I suppose you know about fromcvs. I also guess you know that I suggest using git instead of hg. Doesn't produce nasty large index files either :) So would you think cvs - git - hg might be easier to accomplish ?? Since one of my goals is to update projects Ive done based on FreeBSD that require OS level updating No, I think git is the better SCM, but that's a personal decision. Fromcvs converts to both hg and git, using the same algorithm. I'd appreciate any help fleshing out the last bugs (also re: scalability). I'm considering it beta grade quality, but I know of many people using it on a daily basis without problems. cheers simon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
On 2007-11-14 19:08, Simon 'corecode' Schubert [EMAIL PROTECTED] wrote:
[cc cleaned, dropped -current]
Giorgos Keramidas wrote:
I'm only tracking 'HEAD' most of the time, but there are some efforts
underway to convert the history of src/. One notable example is the
effort to convert to Subversion first, and then use the tags/branches
and changesets of Subversion to populate an Hg tree.
That seems wrong. A conversion to subversion means losing precision
and time.
Can you elaborate a bit. I am not sure I got why you lose precision.
Also cvs20hg doesn't appear to grok Hg branches (probably because it
predates them) and it would be Really Nice(tm) if it did.
cvs20hg is deprecated since two years or so.
I know that. It's just that fromcvs doesn't quite work for me here,
yet, so I had to stick with a patched cvs20hg version.
Please try fromcvs instead. There are some bugs left, of course.
Last thing it seems I introduced some memory overflow problem, so that
a conversion of src now runs out of memory (on a 32bit machine). Up
to a couple of months ago this was running very smoothly, see [1].
Something is missing for [1], I guess :)
I tried fromcvs to the doc/ tree (non-branched, less repo-surgery
magic to handle), but it stops with a traceback very soon:
% $ pwd
% /home/keramida/hg/fromcvs/fromcvs
% $ ruby tohg.rb /home/ncvs doc ~/tmp/foo
% [...]
% /home/ncvs/doc/bn_BD.ISO10646-1/articles/new-users
% /home/ncvs/doc/bn_BD.ISO10646-1/articles/explaining-bsd
% /home/ncvs/doc/FAQ/Attic
% upgrading roberto to 1/ (1.1.1)
% Traceback (most recent call last):
% File ./tohg.py, line 102, in module
% destrepo.dispatch()
% File ./tohg.py, line 98, in dispatch
% func(*l[1:])
% File ./tohg.py, line 78, in cmd_commit
% extra = {'branch': branch})
% TypeError: commit() got an unexpected keyword argument 'wlock'
% tohg.rb:200:in `readline': end of file reached while handling set
[doc/handbook/Attic/troubleshooting.sgml,v:1.1.1.1,doc/handbook/Attic/sup.sgml,v:1.1.1.1,doc/handbook/Attic/slips.sgml,v:1.1.1.1,doc/handbook/Attic/slipc.sgml,v:1.1.1.1,doc/handbook/Attic/scsi.sgml,v:1.1.1.1,doc/handbook/Attic/ppp.sgml,v:1.1.1.1,doc/handbook/Attic/ports.sgml,v:1.1.1.1,doc/handbook/Attic/porting.sgml,v:1.1.1.1,doc/handbook/Attic/nfs.sgml,v:1.1.1.1,doc/handbook/Attic/submitters.sgml,v:1.1.1.1,doc/handbook/Attic/kerberos.sgml,v:1.1.1.1,doc/handbook/Attic/handbook.sgml,v:1.1.1.1,doc/handbook/Attic/glossary.sgml,v:1.1.1.1,doc/handbook/Attic/diskless.sgml,v:1.1.1.1,doc/handbook/Attic/dialup.sgml,v:1.1.1.1,doc/handbook/Attic/eresources.sgml,v:1.1.1.1,doc/handbook/Attic/current.sgml,v:1.1.1.1,doc/handbook/Attic/ctm.sgml,v:1.1.1.1,doc/handbook/Attic/basics.sgml,v:1.1.1.1,doc/handbook/Attic/authors.sgml,v:1.1.1.1,doc/handbook/Attic/bibliography.sgml,v:1.1.1.1]
(EOFError)
% from tohg.rb:200:in `_commit'
% from tohg.rb:122:in `create_branch'
% from ./fromcvs.rb:989:in `commit_sets'
% from tohg.rb:228
% $
I don't know how to read Ruby code, so I can't fix this myself, but any
ideas/help/patches you have I can test easily :)
However I don't think that using named branches in hg is a nice or
elegant thing anyways. But that's OT, of course.
We agree violently about named branches in Hg.
I suppose you know about fromcvs. I also guess you know that I
suggest using git instead of hg. Doesn't produce nasty large index
files either :)
I wasn't aware that you strongly prefer Git. Any references I can read,
so find out more about why you do?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
Giorgos Keramidas wrote:
I'm only tracking 'HEAD' most of the time, but there are some efforts
underway to convert the history of src/. One notable example is the
effort to convert to Subversion first, and then use the tags/branches
and changesets of Subversion to populate an Hg tree.
That seems wrong. A conversion to subversion means losing precision
and time.
Can you elaborate a bit. I am not sure I got why you lose precision.
This is due to the fact that CVS doesn't have changesets. It is too
late now and it is also quite complicated to explain, but it boils down
to the fact that aggregating changesets will remove information, namely
the single file revisions, which you could use for a direct conversion
to hg/git.
Also cvs20hg doesn't appear to grok Hg branches (probably because it
predates them) and it would be Really Nice(tm) if it did.
cvs20hg is deprecated since two years or so.
I know that. It's just that fromcvs doesn't quite work for me here,
yet, so I had to stick with a patched cvs20hg version.
I am surprised that cvs20hg works better. Fromcvs allows you to ignore
certain branches, maybe that's what you need?
Please try fromcvs instead. There are some bugs left, of course.
Last thing it seems I introduced some memory overflow problem, so that
a conversion of src now runs out of memory (on a 32bit machine). Up
to a couple of months ago this was running very smoothly, see [1].
Something is missing for [1], I guess :)
yes, sorry.
[1] http://www.theshell.com/cgi-bin/gitweb.cgi/
I tried fromcvs to the doc/ tree (non-branched, less repo-surgery
magic to handle), but it stops with a traceback very soon:
% $ pwd
% /home/keramida/hg/fromcvs/fromcvs
% $ ruby tohg.rb /home/ncvs doc ~/tmp/foo
% [...]
% /home/ncvs/doc/bn_BD.ISO10646-1/articles/new-users
% /home/ncvs/doc/bn_BD.ISO10646-1/articles/explaining-bsd
% /home/ncvs/doc/FAQ/Attic
% upgrading roberto to 1/ (1.1.1)
% Traceback (most recent call last):
% File ./tohg.py, line 102, in module
% destrepo.dispatch()
% File ./tohg.py, line 98, in dispatch
% func(*l[1:])
% File ./tohg.py, line 78, in cmd_commit
% extra = {'branch': branch})
% TypeError: commit() got an unexpected keyword argument 'wlock'
% tohg.rb:200:in `readline': end of file reached while handling set
[doc/handbook/Attic/troubleshooting.sgml,v:1.1.1.1,doc/handbook/Attic/sup.sgml,v:1.1.1.1,doc/handbook/Attic/slips.sgml,v:1.1.1.1,doc/handbook/Attic/slipc.sgml,v:1.1.1.1,doc/handbook/Attic/scsi.sgml,v:1.1.1.1,doc/handbook/Attic/ppp.sgml,v:1.1.1.1,doc/handbook/Attic/ports.sgml,v:1.1.1.1,doc/handbook/Attic/porting.sgml,v:1.1.1.1,doc/handbook/Attic/nfs.sgml,v:1.1.1.1,doc/handbook/Attic/submitters.sgml,v:1.1.1.1,doc/handbook/Attic/kerberos.sgml,v:1.1.1.1,doc/handbook/Attic/handbook.sgml,v:1.1.1.1,doc/handbook/Attic/glossary.sgml,v:1.1.1.1,doc/handbook/Attic/diskless.sgml,v:1.1.1.1,doc/handbook/Attic/dialup.sgml,v:1.1.1.1,doc/handbook/Attic/eresources.sgml,v:1.1.1.1,doc/handbook/Attic/current.sgml,v:1.1.1.1,doc/handbook/Attic/ctm.sgml,v:1.1.1.1,doc/handbook/Attic/basics.sgml,v:1.1.1.1,doc/handbook/Attic/authors.sgml,v:1.1.1.1,doc/handbook/Attic/bibliography.sgml,v:1.1.1.1]
(EOFError)
% from tohg.rb:200:in `_commit'
% from tohg.rb:122:in `create_branch'
% from ./fromcvs.rb:989:in `commit_sets'
% from tohg.rb:228
% $
I don't know how to read Ruby code, so I can't fix this myself, but any
ideas/help/patches you have I can test easily :)
This is because mercurial changes its API on every release. Somebody
who is using hg and fromcvs needs to update the code. I got tired of this.
I suppose you know about fromcvs. I also guess you know that I
suggest using git instead of hg. Doesn't produce nasty large index
files either :)
I wasn't aware that you strongly prefer Git. Any references I can read,
so find out more about why you do?
Sorry, I didn't write up the reasons. It's more of a personal feeling
and a preference for the git repository layout. This layout allows many
things to be implemented in a very simple way (ref. branches). Also, it
is better suited to have multiple branches in a repo, which is usually
what you want to do if you're syncing with multiple persons. Hg only
has heads.
cheers
simon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
On 15/11/2007, Simon 'corecode' Schubert [EMAIL PROTECTED] wrote: This is due to the fact that CVS doesn't have changesets. It is too late now and it is also quite complicated to explain, but it boils down to the fact that aggregating changesets will remove information, namely the single file revisions, which you could use for a direct conversion to hg/git. Just a random data point; Henrik Nordstrom put up some CVS changeset thing for Squid which personally I find rather nifty. For example: http://www.squid-cache.org/Versions/v2/HEAD/changesets/ -- Adrian Chadd - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
On 2007-11-09 11:23, Julian Elischer [EMAIL PROTECTED] 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 10 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 +
summary: Import FreeBSD src/ snapshot at 2007/07/16 17:03:48 +
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 +
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/:
[EMAIL PROTECTED]:/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
[EMAIL PROTECTED]:/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/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
On Tue, 13 Nov 2007 21:45:30 +0200 Giorgos Keramidas [EMAIL PROTECTED] wrote:
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.
Actually, it is easy. Well, sort of, as whether or not what you're
doing is a mirror depends on how you want to define 'mirror'. It
looks and acts like a read-only local copy, but it isn't. Instead,
your server fetches the bits it needs from the remote server on
demand.
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.
What you want to do is set up the master (where you are mirroring
from) as a remote depot on your local server. You then treat the
appropriate part of that as the vendor branch. You treat it just
like you'd treat a vendor branch most other SCMs - except you don't
have to import new vendor code. You need local changes? Create a
local branch of the vendor branch, and work there. You need to merge
vendor changes into your branch? You do it just like you would if it
were in the local repository. You want to grovel through the change
logs of the vendor branch? Those are there as well, just like they are
in a distributed SCM.
It isn't the same as having a local repository in a distributed SCM,
so the advantages and disadvantages are different. Whether or not
it'll do the job you want depends on the exact nature of the job. But
I've been happy doing things this way.
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
On Wed, 14 Nov 2007, Giorgos Keramidas wrote: * 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: I have seen a few Hg repos although I haven't found one for RELENG_7 [yet]. Also cvs20hg doesn't appear to grok Hg branches (probably because it predates them) and it would be Really Nice(tm) if it did. (ENOCLUE is my excuse for a lack of patches :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: questions on development(7)
All ive seen in FreeBSD hg branches is a current and a releng_6 Id like to see a complete tree converted if there is one out there. I do have some bandwidth to potentially host such a conversion for others. question is does one exist ? On Wed, 2007-11-14 at 17:48 +1030, Daniel O'Connor wrote: On Wed, 14 Nov 2007, Giorgos Keramidas wrote: * 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: I have seen a few Hg repos although I haven't found one for RELENG_7 [yet]. Also cvs20hg doesn't appear to grok Hg branches (probably because it predates them) and it would be Really Nice(tm) if it did. (ENOCLUE is my excuse for a lack of patches :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
2. If yes to #1 how do I setup keeping everything except my modified code in sync (and if possible to retro activally apply patchs from the local branch unto the main source tree [/usr/src2]) You won't be able to commit to the BSD repo from your server. I think you should treat your repo as read only and use cvsup to keep it up to date. At least that's what I do. What I meant was how do I keep from clobbering my local changes? -- Aryeh M. Friedman Developer, not business, friendly http://www.flosoft-systems.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If you keep a local repo, and checkout from the local repo, then your checkout will merge the changes (unless there are conflicts). Thanks the fact I know the answer you gave is quite simple but completely over my head shows I need a good tutorial on cvs where can I find one ;-) - -- Aryeh M. Friedman Developer, not business, friendly http://www.flosoft-systems.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHM/R1J9+1V27SttsRAhdgAJ9HVh/Zzfu1oUgnGqcLAIpGHsHOKgCfVuzL xhJ83RXcG8gVAX9KUEK5wPQ= =ADE2 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
On Fri, Nov 09, 2007 at 04:56:24AM +, Aryeh M. Friedman wrote: 1. If I am modifing code and such should I have a local branch? You can either maintain a local branch or keep backing up your diffs against the main source tree. Which one is better depends on the size of your changes and your workflow. I've used both. Maintaining your own local branch means much more cvs-related overhead but may be worth it if you need your changes versioned properly. 2. If yes to #1 how do I setup keeping everything except my modified code in sync (and if possible to retro activally apply patchs from the local branch unto the main source tree [/usr/src2]) Just run cvsup to update your copy of the cvs repository as usual, it should not delete your branch. The development(7) man page says that it can in some cases delete your branch though, so you should regularly back up your branch as a diff against the upstream branch you are based on, and possibly back up your copy of the cvs repository before updating. 3. The documentation said very little about how to generate patchs between my local code and the main branch a. Ideally I want to set it up where when I am done with a modification it automatically creates a patch (I have never used CVS for anything except through csup and cvsup so I am totally lost here) I don't think this list is appropriate for basic CVS questions, but I give you a few hints anyway because development(7) does not mention them: You need to tag the point you are branching from in CVS, otherwise you cannot create meaningful diffs between your own branch and the upstream branch. So to create a branch you can actually use, you need to run the rtag command TWICE. For example, to branch RELENG_7, use: export CVS_LOCAL_BRANCH_NUM=424242 cvs -d $CVSROOT rtag -r RELENG_7 MY_BRANCH_BP cvs -d $CVSROOT rtag -r RELENG_7 -b MY_BRANCH You should also create descriptive tags on both branches before and after doing a merge, to make it easier to track what has been merged where and when. Otherwise continuously syncing your branch with upstream becomes a pain quickly. You can maintain several custom branches in a single repository by switching CVS_LOCAL_BRANCH_NUM. Just don't end up confusing your branches. Always use the same CVS_LOCAL_BRANCH_NUM setting for all tag and rtag commands operating on the same branch. Warning: Branching and merging in CVS is hard! Not because branching and merging in general is hard, but simply because CVS is brain damaged. You will very likely mess it up the first time. You should practise on a test repo until you feel confident that you understand it properly. For more information see http://cvsbook.red-bean.com/ and especially http://cvsbook.red-bean.com/cvsbook.html#Branches -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpJtXFRst0hc.pgp Description: PGP signature
Re: questions on development(7)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OutbackDingo wrote: well thats kinda hard to do with CVS, though other revision systems such as mercurial, bazaar, git and perforce, even subversion do it well, there is also a mercurial respository for FreeBSD out there some where If I need to use an other CMS I would prefer aegis... and if that is the case I will volunteer to maintain the aegis---cvs repo... but there has to be a better way then using yet an other package - -- Aryeh M. Friedman Developer, not business, friendly http://www.flosoft-systems.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHM/YRJ9+1V27SttsRAvBZAJ0WyR9zsc5d+8yYniiG543+pqlfWwCgpWj/ VIlqef2f+3/W7bALCHYlXc0= =34ww -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
On Nov 8, 2007, at 11:36 PM, Aryeh M. Friedman wrote: 2. If yes to #1 how do I setup keeping everything except my modified code in sync (and if possible to retro activally apply patchs from the local branch unto the main source tree [/usr/src2]) You won't be able to commit to the BSD repo from your server. I think you should treat your repo as read only and use cvsup to keep it up to date. At least that's what I do. What I meant was how do I keep from clobbering my local changes? If you keep a local repo, and checkout from the local repo, then your checkout will merge the changes (unless there are conflicts). Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
Aryeh M. Friedman wrote: First of all I am posting to both -current and -hackers because -hackers seems to be very low volume. I just set up a master server development server using the procedure in development(7) which was fairly clear but left a few questions unanswered (and one odd behavior). I have only the master server (no clients). Just for ref my dir tree looks like this: /home/ncvs --- /FreeBSD/CVSROOT /FreeBSD/7.x (src) /FreeBSD/current (src ports doc) /usr/src --- /FreeBSD/7.x /usr/src2 --- /FreeBSD/current /usr/ports --- /FreeBSD/current/ports /usr/obj is on it's own partition My questions: 1. If I am modifing code and such should I have a local branch? 2. If yes to #1 how do I setup keeping everything except my modified code in sync (and if possible to retro activally apply patchs from the local branch unto the main source tree [/usr/src2]) You won't be able to commit to the BSD repo from your server. I think you should treat your repo as read only and use cvsup to keep it up to date. At least that's what I do. 3. The documentation said very little about how to generate patchs between my local code and the main branch a. Ideally I want to set it up where when I am done with a modification it automatically creates a patch (I have never used CVS for anything except through csup and cvsup so I am totally lost here) 'cvs diff' will generate a patch for the specified files or directories. Some like context diffs, I like unified with minimal context '-ud' option to diff. Use whichever you find easier to read. Submit patches in whatever format the developers prefer. Unified seems the most common format around here. Ian -- Ian Freislich ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
well thats kinda hard to do with CVS, though other revision systems such as mercurial, bazaar, git and perforce, even subversion do it well, there is also a mercurial respository for FreeBSD out there some where On Fri, 2007-11-09 at 05:36 +, Aryeh M. Friedman wrote: 2. If yes to #1 how do I setup keeping everything except my modified code in sync (and if possible to retro activally apply patchs from the local branch unto the main source tree [/usr/src2]) You won't be able to commit to the BSD repo from your server. I think you should treat your repo as read only and use cvsup to keep it up to date. At least that's what I do. What I meant was how do I keep from clobbering my local changes? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
On Fri, 2007-11-09 at 21:49 +0800, OutbackDingo wrote: well thats kinda hard to do with CVS, though other revision systems such as mercurial, bazaar, git and perforce, even subversion do it well, there is also a mercurial respository for FreeBSD out there some where On Fri, 2007-11-09 at 05:36 +, Aryeh M. Friedman wrote: 2. If yes to #1 how do I setup keeping everything except my modified code in sync (and if possible to retro activally apply patchs from the local branch unto the main source tree [/usr/src2]) You won't be able to commit to the BSD repo from your server. I think you should treat your repo as read only and use cvsup to keep it up to date. At least that's what I do. What I meant was how do I keep from clobbering my local changes? (Nothing like top posting to destroy the thread flow) OutbackDingo is incorrect. That is the entire purpose of CVS, otherwise they might as well call it VS.. Your /usr/src will be a checkout of a particular branch of freebsd (called a working copy). You periodically update your cvs repository (where you checkout from) with the latest freebsd commits. When you wish to, you update your working copy from your repository by issuing a 'cvs up'. This merges changes in the repository into your local copy, merging in with the local changes. When you want to see what has changed since you last did a 'cvs up', issue a 'cvs -n up'. When you want to see the local modifications in your working copy, issue a 'cvs diff'. Read the cvs red-bean book for more info. http://cvsbook.red-bean.com/cvsbook.html HTH Tom signature.asc Description: This is a digitally signed message part
Re: questions on development(7)
On Fri, 2007-11-09 at 14:43 +, Tom Evans wrote: On Fri, 2007-11-09 at 21:49 +0800, OutbackDingo wrote: well thats kinda hard to do with CVS, though other revision systems such as mercurial, bazaar, git and perforce, even subversion do it well, there is also a mercurial respository for FreeBSD out there some where On Fri, 2007-11-09 at 05:36 +, Aryeh M. Friedman wrote: 2. If yes to #1 how do I setup keeping everything except my modified code in sync (and if possible to retro activally apply patchs from the local branch unto the main source tree [/usr/src2]) You won't be able to commit to the BSD repo from your server. I think you should treat your repo as read only and use cvsup to keep it up to date. At least that's what I do. What I meant was how do I keep from clobbering my local changes? (Nothing like top posting to destroy the thread flow) OutbackDingo is incorrect. That is the entire purpose of CVS, otherwise they might as well call it VS.. Your /usr/src will be a checkout of a particular branch of freebsd (called a working copy). You periodically update your cvs repository (where you checkout from) with the latest freebsd commits. When you wish to, you update your working copy from your repository by issuing a 'cvs up'. This merges changes in the repository into your local copy, merging in with the local changes. When you want to see what has changed since you last did a 'cvs up', issue a 'cvs -n up'. When you want to see the local modifications in your working copy, issue a 'cvs diff'. Read the cvs red-bean book for more info. http://cvsbook.red-bean.com/cvsbook.html HTH Tom Well I wouldnt say incorrect as i stated it was hard to do. Meaning its easier to complete these tasks with a different RCS, in my OWN opinion. So as not to clobber ones changes locally. I didnt say it could not be done, its simply more difficult to achieve the same result as with other RCS systems. The reason I sated as more difficult to do, Ive seen quite a number of times when tracking a vendor branch, that merges had to be more manually handled because of local changes. This is another of those preferences people get into wars over, Best OS, Browser, RCS etc etc etc... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
On Fri, 2007-11-09 at 05:47 +, Aryeh M. Friedman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If you keep a local repo, and checkout from the local repo, then your checkout will merge the changes (unless there are conflicts). Thanks the fact I know the answer you gave is quite simple but completely over my head shows I need a good tutorial on cvs where can I find one ;-) O'Reilly released a good book a while back that has a free version online: http://cvsbook.red-bean.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
On 2007-11-09 21:49, OutbackDingo [EMAIL PROTECTED] wrote: well thats kinda hard to do with CVS, though other revision systems such as mercurial, bazaar, git and perforce, even subversion do it well, there is also a mercurial respository for FreeBSD out there some where That is cool, but it takes a bit of familiarity with both CVS *and* the target SCM, so it may be worth sticking with CVS for a while. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
On Thursday 08 November 2007, Aryeh M. Friedman said: First of all I am posting to both -current and -hackers because -hackers seems to be very low volume. Please do not cross post. It is considered bad form and generates thousands of unnecessary emails. Beech -- --- Beech Rintoul - FreeBSD Developer - [EMAIL PROTECTED] /\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://www.freebsd.org X - NO Word docs in e-mail | Latest Release: / \ - http://www.FreeBSD.org/releases/6.2R/announce.html --- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on development(7)
You won't be able to commit to the BSD repo from your server. Well, Aryeh wants to commit to a _local_ copy of the BSD repo. This works. See development(7). One thing the man page does not mention is that you need to change the commit hook in CVSROOT (which you only copy on first sync and never ever again) to simply 'exit 0' to allow commits. -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpSKYuK7dRID.pgp Description: PGP signature
Re: questions on development(7)
OutbackDingo wrote: On Fri, 2007-11-09 at 14:43 +, Tom Evans wrote: On Fri, 2007-11-09 at 21:49 +0800, OutbackDingo wrote: well thats kinda hard to do with CVS, though other revision systems such as mercurial, bazaar, git and perforce, even subversion do it well, there is also a mercurial respository for FreeBSD out there some where On Fri, 2007-11-09 at 05:36 +, Aryeh M. Friedman wrote: 2. If yes to #1 how do I setup keeping everything except my modified code in sync (and if possible to retro activally apply patchs from the local branch unto the main source tree [/usr/src2]) You won't be able to commit to the BSD repo from your server. I think you should treat your repo as read only and use cvsup to keep it up to date. At least that's what I do. What I meant was how do I keep from clobbering my local changes? (Nothing like top posting to destroy the thread flow) OutbackDingo is incorrect. That is the entire purpose of CVS, otherwise they might as well call it VS.. Your /usr/src will be a checkout of a particular branch of freebsd (called a working copy). You periodically update your cvs repository (where you checkout from) with the latest freebsd commits. When you wish to, you update your working copy from your repository by issuing a 'cvs up'. This merges changes in the repository into your local copy, merging in with the local changes. When you want to see what has changed since you last did a 'cvs up', issue a 'cvs -n up'. When you want to see the local modifications in your working copy, issue a 'cvs diff'. Read the cvs red-bean book for more info. http://cvsbook.red-bean.com/cvsbook.html HTH Tom Well I wouldnt say incorrect as i stated it was hard to do. Meaning its easier to complete these tasks with a different RCS, in my OWN opinion. So as not to clobber ones changes locally. I didnt say it could not be done, its simply more difficult to achieve the same result as with other RCS systems. The reason I sated as more difficult to do, Ive seen quite a number of times when tracking a vendor branch, that merges had to be more manually handled because of local changes. This is another of those preferences people get into wars over, Best OS, Browser, RCS etc etc 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 10 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. 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.. etc... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
