:Absolutely. I'd like to take this a step further: Mailing patches and
:explaining users how to apply the patch ("first revert patch #3, then
:apply this, then apply patch #3a") is bothersome. I'd like to be able to
:push my changes somewhere (like on a leaf "official private repo") and
:have people pull the changes from there.
I agree with this sentiment. Whatever we choose must facilitate
an ability by all DragonFly developers to serve out change sets
via their leaf accounts.
:> This would mean anonymous access and having the utility as part of base.
:> There may be a better strategy; I'm thinking in terms of the functionality
:> we use now with CVS and cvsup.
:
:I absolutely do not think that the tool has to be part of base. cvsup is
:not part of base either. An existing pkgsrc binary package on the iso
:shoud suffice.
:
:cheers
: simon
I want to huck cvsup into the dumpster. Whatever source system we use
needs to have a native remote update capability... and I think all the
ones we are currently contemplating already do, don't they? SVN and
GIT both certainly do.
-Matt
Matthew Dillon
<dillon@backplane.com>| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| debian developer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Vu Pham | Re: [Scst-devel] Integration of SCST in the mainstream Linux kernel |
| Adrian Bunk | Re: Linux 2.6.21 |
git: | |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Radu Rendec | Endianness problem with u32 classifier hash masks |
| Benjamin Herrenschmidt | [PATCH 0/11] ibm_newemac: Candidate patches for 2.6.25 |
