On Thu, Oct 23, 2008 at 07:36:50AM -0500, Hyrum K. Wright wrote:
> Greg Stein wrote:
> > Yes. And to that point, let me formally suggest a /patches/ directory,
> > as a sibling to /branches/. We can put developer-work in there, and we
> > can also drop third-party patches in there, too, pending
> > review/tweaking/application (rather than attach them to the issue
> > tracker, for example).
>
> I think this would be a good way to help tidy up /branches/ we've got at least a
> few trees in there which were added as patches, and then never touched again.
> Having a way to differentiate them from active, long-lived branches would be useful.
So what are active, long-lived branches and what are patches?
To me this looks like we'd end up having just stable release branches
in /branches/, and everything else that's not in trunk (yet) in /patches/?
I've added a branch recently to work on issue #2382. I created the branch
for the same reasons Julian mentioned -- I started working on a patch,
found that I needed to checkpoint my work because I need to experiment
a bit to get it right. So I created a branch. The aim for the end result
is to get a reviewable patch that sits on the branch, ready to be merged
into trunk. Since the /branches/ directory has been used like this for quite
some time, and because it's not clear to me where to draw the line between
"active & long-lived" and "patch" (if not between release branches and
everything else), I don't see why we need another directory.
But I don't care too much -- as long as I can have some place in the repo
to checkpoint my work without having to step on anyone's toes, I'm happy.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-25 15:42:44 CEST