On Mon, Jul 02, 2007 at 09:54:47PM -0400, Garance A Drosihn wrote:
> And I *have* access to the FreeBSD repository. What about
> someone who doesn't have any access, but wants to work on
> some changes before sending in a PR? How are they supposed
> to come up with a patch that they are confident in?
I used the CVS_LOCAL_BRANCH_NUM feature to work on my wake
on lan patch for FreeBSD (http://stsp.name/wol/).
It's described in development(7). You create a copy of the
FreeBSD CVS repo, create a local branch with a revision number
you make up and commit to the branch, hoping that there will never
be a branch with the same number in the official repo.
CVSup will (in most cases) manage to keep your branch intact
when you sync to the master repo.
I think this feature was hacked into CVS by the FreeBSD people
to facilitate customisation. I don't know how many people actually
make use of it, and in fact I stopped using it after a while out of
lazyness, and now I just maintain my patch against a workspace from
anoncvs. But that only works because the patch is rather small.
And doing this makes it hard for me to track -CURRENT :-/
> Should they send in one PR one day, and then send in another PR the
> next day saying "Well, my previous patch was all screwed up,
> but how about this one?". This is not a good way to build
> credibility.
My patch has been sitting around for more than 2 years now.
A few users have asked for it to go into mainline,
but I have no committer at hand who can nitpick and commit it
for me, even though I've asked several times no one seems
interested :(
This is a social problem though, not a technical one.
</freebsd>
<subversion>
> I think what I want is to be able to create my own repository,
> and maybe say that the HEAD branch in this new repository is a
> read-only copy of HEAD in the master repository. The local
> HEAD branch would automatically sync-up with the original.
That would be nice indeed. I'm also working on the port
of Linux to the Nintendo DS console, and we are using
subversion. For people without commit access the only
option currently is to create patches against anonsvn
and send them to the mailing list. They don't really
learn how to use version control properly doing this,
which is a problem because it means there's an additional
learning curve involved in becoming a committer.
And a lot of patches we get are not well done. Maybe if
people submitting patches had more of an idea of how version
control actually works they would send better patches.
It would be great if subversion could educate people this way.
> This obviously presents some technical issues wrt revision
> numbers, etc. Perhaps that could be tracked via a second
> revprop for the mirrored version of the HEAD branch.
This would be interesting to implement :)
The company I work for does SCM consulting and is also focusing
on distributed development. A lot of our clients use subversion
at the moment. Getting more distributed development features into
subversion would be great, and I think we'd gladly help designing
and implementing them.
> And really I'd like to specify more than one branch.
> Something like "Create me a new repository which is a fork
> of <OtherRespository>, starting at July 1/2006, and limit
> that mirroring to just the HEAD and 6.x branches".
Since branches are just directories in subversion, selecting
a subset of directories from the repo you are mirroring
should be relatively trivial to implement.
--
Stefan Sperling <stsp@elego.de> Software Developer
elego Software Solutions GmbH HRB 77719
Ohmstrasse 9 Tel: +49 30 40 04 19 29
10179 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de Geschaeftsfuehrer: Olaf Wagner
- application/pgp-signature attachment: stored
Received on Tue Jul 3 14:05:24 2007