[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PROPOSAL] Create branch for repository mirroring?

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-12-13 15:34:22 CET

Justin Erenkrantz <jerenkrantz@apache.org> writes:
> I'm not looking for a code review at this point - hence, no log
> message. I won't even tell you how to use it, or configure it. If
> you sift through the code, you can figure it out though.

Oh :-). Okay, then I'll wait, thanks.

> I know where there is room for improvement, but I'm guessing I'd like
> a sandbox where I can work on this and share my work with
> others. Eventually, I believe this could be merged into the trunk.
> I'm just not ready for that yet, and I don't care to keep maintaining
> patches like these on my local machine. This stuff really needs to be
> versioned somewhere! Due to the lack of cross-repository merges, I
> couldn't even setup a server to do this right on my own. Stuff like
> this has to live in the CollabNet repository. -- justin

Sure, but if it's going to go even on a branch, it still needs a log
message and documentation. The branch isn't useful to others unless
meets the same sandbox standards as the rest of Subversion.

Hmmm, I guess we haven't really had this discussion yet. This is as
good a time as any... What I'm proposing is a basic policy on
experimental branches in general:

   Experimental branches are great as long as they're conducted the
   same way as trunk development -- with the exception that they don't
   necessarily have to build and pass 'make check' at all times (the
   group maintaining the branch can decide about that; I mean, there's
   a reason it's called "experimental"! :-) ). But as far as log
   messages and documentation go, branches should be as thorough as
   trunk, because people rely on that information to follow branch

It is not costless for our repository to version an experimental
branch. If the branch is there, people will look at it. It will get
discussed on the list. People will start filing issues against it in
the database, etc, etc. None of which is bad, of course; it's just
that to work well with these processes, the branch needs to meet
certain expectations.

There's no point having a bunch of code dumped into the repository if
only one or two people know what state it's in and how to use it. It
has to be consumable by everyone.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 13 16:14:07 2002

This is an archived mail posted to the Subversion Dev mailing list.