--On Tuesday, December 03, 2002 12:05:08 -0600 Ben Collins-Sussman
<sussman@collab.net> wrote:
> world. We've criticized gat for this, as well as mbk, and we'd like
> to discourage others from repeating this behavior in the future. So
> pretty please, ghudson, don't write libsvn_fs_fs in cave!
Then, what is the policy for creating branches?
I've got several things in my cave that haven't been accepted. Almost all
of them have been submitted to the list, but not included for various
reasons. Some are due to time constraints on my end, and others due to
conflicting world views among SVN developers.
1) svn:permissions
Bill and Branko refuse to accept it until it can handle Win32
permissions, which of course, is downright near impossible. And, we're
diametrically opposed on whether SVN should even do this or not. (Not
looking to bring this discussion up again - I was obviously in the minority
on this.)
2) Using APR's libtool rather than SVN's own generated libtool
This is required to use my jlibtool, but someone complained that SVN
needed its own libtool rather than using APR's. My current version ensures
the APR libtool is new enough for SVN, but still...
3) Adding a --with-diffutils option to configure
Solaris's diff isn't good enough, and forcing me to include a good diff
in my PATH is, um, icky. But, the ac-helpers/check-diff.sh is bypassed
with an explicit value passed - no time to clean that up by rewriting
check-diff.sh as an M4 macro.
4) My update of mbk's svn switch --relocate patch
I haven't had time to catch up with the Issue #1000 patch which fixes
loggy wcprops. I think the patch works even in that case, but I haven't
had time to sift through that new code. As those in Vegas know, I merged
that code into my tree while I was there. I also fixed up a bunch of minor
nits in mbk's original patch.
5) My 'mirror' repos code
I just wrote this code, but perhaps others would be interested in
having this functionality. At the very least, it'd be a jumping-off point
for thinking about distributed SVN repositories.
Branches may be good for work we know will be merged, but what about stuff
that might not be merged or not all developers agree on whether it should
be in?
I don't necessarily have the time to meet the requirements of every
developer to get all of my patches accepted. It's just that people keep
asking about some of my functionality and I can't say it's in HEAD or even
within SVN itself. I have to provide diff-style patches myself. So, yeah,
branches would be goodness, but I have a hunch what I would want in a
branch wouldn't be approved. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 4 00:16:45 2002