Henri Yandell wrote:
On 1/18/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
Henri Yandell wrote:
> On 1/18/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
>> All,
>>
>> I just wanted to give a heads up that I am currently thinking that
>> blogs.sun.com could use its own place in Roller subversion for
>> branching/tagging our own releases. The basic situation is that we
>> develop and deploy at a faster rate than the project releases
happen and
>> often times we deploy from builds of the active trunk. Up until
now we
>> have tried to manage any branching/tagging for releases on our own
side,
>> but it would make things a lot easier to branch/tag directly in the
>> Roller repository.
>>
>> So, would anyone object to me creating a separate area in Roller
svn for
>> maintaining up to a handful of BSC branches/tags?
>
> -1.
>
> I understand the desire - I'm maintaining patches for open source
> projects locally for some projects and it can get painful. But this
> would be a very bad precedent, only the PMC make releases. Also it'd
> definitely be bad for it to be a branch rather than a tag, effectively
> a private fork within the project. This came up previously, though I
> don't remember what the project was and the opinion was definitely
> negative.
I probably didn't explain what I needed properly, but I think you make
it sound worse than it is. The only thing this would be used for is to
be able to branch certain revisions of the trunk for short periods of
time. There is no forking or developing planned to happen in these
copies, they are merely meant to be there as a way to mitigate the
potential problem that can be caused when we plan to make use of a
certain revision of the trunk for a deployment while other folks may be
continuing to commit things.
What's the problem with that?
You decide to use r128191, a commit is made and trunk moves on, but
your revision is still the same. It's the same as making a tag for it
and avoids what seems to be like an abnormal use of an apache
repository.
The main problem is that I would also want to be able to merge in some
specific revisions rather than just being a tag. i.e. make a branch at
a given revision, then someone else commits something that is not
totally stable, then I commit a small bug fix which I want included in
the branch.
Doing something like that via svnsync or some other method becomes more
complicated and IMO is exactly what the repository is for.
(snip...)
So for example, I have a need to deploy basically what is currently in
the trunk. However, Dave and Mitesh are working on some things which
are hacking away at the backend and I don't want to have that work
disrupt my deployment. So, what you normally do is create a branch and
then I can merge in whatever changes I want until the trunk stabilizes
again.
I think the normal options would either be:
1) The new work is a research feature - therefore Dave/Mitesh work on
a branch and it gets merged into the trunk when it's ready.
or
2) The new work is a part of the new release and the stable version is
maintained on a branch.
right. and i am suggesting this case is #2, where i want to stabilize
things in a branch so that others can keep working out of the trunk
unhindered.
i will look into svnsync more closely, but part of me still thinks it's
a shame to force people to copy the repository rather than use the
repository directly.
-- Allen
Hen
