You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Aaron Mulder <am...@alumni.princeton.edu> on 2004/11/05 00:11:23 UTC
SVN Branches
Is there a way to branch a few files or directories and leave the
rest of the server tracking with the trunk?
For example, if I wanted to branch security or deployment, in such
a way that you could check out my branch and get the most current versions
of everything, except my versions of security or deployment.
The best I've heard is to branch everything, apply my changes, and
then continually merge changes from trunk to branch. This has 2 problems:
1) I have to keep track of the last trunk rev I merged to the branch so
that next time I can only merge from that point to the current rev
2) I have to resolve conflicts in my branched code, if there were any
trunk changes to that
Thanks,
Aaron
Re: SVN Branches
Posted by Dain Sundstrom <ds...@gluecode.com>.
Sorry, I thought there was a follow option.... guess I was wrong.
-dain
On Nov 4, 2004, at 5:32 PM, Aaron Mulder wrote:
> I like to think that I'm not an idiot (though I am getting a
> littly grumpy, for which I apologize). I reread the entire branching
> chapter in the Subversion book, and it looks like the options are
> exactly
> as I stated -- once you make the branch, the trunk marches on, and the
> only way to keep the branch up to date with the trunk is to continually
> merge the trunk to the branch using very specific revision numbers. In
> other words, if your copy was done at revision 123, and a file you
> didn't
> change gets 3 more changes on the trunk after that, your copy still
> shows
> the file as it was in revision 123, until you merge all the changed
> from
> 123:HEAD on the trunk into your branch.
>
> They recommend you keep track of which revisions you've already
> merged in your commit messages, which seems ridiculous to me, since the
> commit message only applies to the files that were actually changed (so
> you don't know what you merged for the branch as a whole without
> examinging every single file). I think it would be better to keep a
> text
> file in the root dir listing the last trunk revision you merged to your
> branch. But even that seems fairly unpleasant.
>
> So, I ask again, without any more RTFMs, is there any convenient
> way to branch in such a way that all the unmodified files stay in
> lockstep
> with the trunk, and only the modified files are tracked differently?
>
> Thanks,
> Aaron
>
> P.S. Branches were not Jeremy's idea, and I would in fact prefer to
> avoid
> them myself, but I'd like to at least know if there's a good way to do
> it.
>
> On Thu, 4 Nov 2004, Dain Sundstrom wrote:
>
>> On Nov 4, 2004, at 3:51 PM, Geir Magnusson Jr wrote:
>>
>>>
>>> On Nov 4, 2004, at 3:45 PM, Dain Sundstrom wrote:
>>>
>>>> It is covered in the subversion book http://svnbook.red-bean.com/
>>>>
>>>> Can understand why you would want to branch for security, but I
>>>> think
>>>> you should keep working on your deployment stuff in the main trunk.
>>>
>>> If it's easy to fold back in, why not do in a branch? There's
>>> clearly
>>> a difference of opinion here, one in which both sides feel pretty
>>> strongly. Out of respect and courtesy, why not do in a branch if the
>>> downside costs of having to bring it back to trunk are so low?
>>
>> If there are differences they should be aired on this list. I see
>> this
>> as a back channel to not have Aaron implement a feature everyone liked
>> except Jeremy.
>>
>>> It's rather traditional in some other projects I've been in to
>>> demonstrate contrary ideas in a way that guarantees good exposure to
>>> the community, with little disruption.
>>
>> For a stable project that is not under active development, I
>> understand, but everything in geronimo is changing quickly. Should I
>> have implemented disabled gbeans in another branch? Should Alan
>> implement CORBA in a branch? Since this is the first time for someone
>> to branch, I suspicious of the motivations.
>>
>> -dain
>>
>>
Re: SVN Branches
Posted by David Blevins <da...@visi.com>.
On Thu, Nov 04, 2004 at 08:32:47PM -0500, Aaron Mulder wrote:
> So, I ask again, without any more RTFMs, is there any convenient
> way to branch in such a way that all the unmodified files stay in lockstep
> with the trunk, and only the modified files are tracked differently?
>
No, there is not. You get a copy of the code at the time of the
branch. Development in the main trunk will march on without you.
-David
Re: SVN Branches
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I like to think that I'm not an idiot (though I am getting a
littly grumpy, for which I apologize). I reread the entire branching
chapter in the Subversion book, and it looks like the options are exactly
as I stated -- once you make the branch, the trunk marches on, and the
only way to keep the branch up to date with the trunk is to continually
merge the trunk to the branch using very specific revision numbers. In
other words, if your copy was done at revision 123, and a file you didn't
change gets 3 more changes on the trunk after that, your copy still shows
the file as it was in revision 123, until you merge all the changed from
123:HEAD on the trunk into your branch.
They recommend you keep track of which revisions you've already
merged in your commit messages, which seems ridiculous to me, since the
commit message only applies to the files that were actually changed (so
you don't know what you merged for the branch as a whole without
examinging every single file). I think it would be better to keep a text
file in the root dir listing the last trunk revision you merged to your
branch. But even that seems fairly unpleasant.
So, I ask again, without any more RTFMs, is there any convenient
way to branch in such a way that all the unmodified files stay in lockstep
with the trunk, and only the modified files are tracked differently?
Thanks,
Aaron
P.S. Branches were not Jeremy's idea, and I would in fact prefer to avoid
them myself, but I'd like to at least know if there's a good way to do it.
On Thu, 4 Nov 2004, Dain Sundstrom wrote:
> On Nov 4, 2004, at 3:51 PM, Geir Magnusson Jr wrote:
>
> >
> > On Nov 4, 2004, at 3:45 PM, Dain Sundstrom wrote:
> >
> >> It is covered in the subversion book http://svnbook.red-bean.com/
> >>
> >> Can understand why you would want to branch for security, but I think
> >> you should keep working on your deployment stuff in the main trunk.
> >
> > If it's easy to fold back in, why not do in a branch? There's clearly
> > a difference of opinion here, one in which both sides feel pretty
> > strongly. Out of respect and courtesy, why not do in a branch if the
> > downside costs of having to bring it back to trunk are so low?
>
> If there are differences they should be aired on this list. I see this
> as a back channel to not have Aaron implement a feature everyone liked
> except Jeremy.
>
> > It's rather traditional in some other projects I've been in to
> > demonstrate contrary ideas in a way that guarantees good exposure to
> > the community, with little disruption.
>
> For a stable project that is not under active development, I
> understand, but everything in geronimo is changing quickly. Should I
> have implemented disabled gbeans in another branch? Should Alan
> implement CORBA in a branch? Since this is the first time for someone
> to branch, I suspicious of the motivations.
>
> -dain
>
>
Re: SVN Branches
Posted by David Blevins <db...@gluecode.com>.
Motivations, diffusing, back channels.... Can we turn this back into a
technical discussion? Somewhere in the ballpark of a simple +/-1
maybe.
-David
On Nov 4, 2004, at 4:31 PM, Geir Magnusson Jr wrote:
>
> On Nov 4, 2004, at 4:09 PM, Dain Sundstrom wrote:
>
>> On Nov 4, 2004, at 3:51 PM, Geir Magnusson Jr wrote:
>>
>>>
>>> On Nov 4, 2004, at 3:45 PM, Dain Sundstrom wrote:
>>>
>>>> It is covered in the subversion book http://svnbook.red-bean.com/
>>>>
>>>> Can understand why you would want to branch for security, but I
>>>> think you should keep working on your deployment stuff in the main
>>>> trunk.
>>>
>>> If it's easy to fold back in, why not do in a branch? There's
>>> clearly a difference of opinion here, one in which both sides feel
>>> pretty strongly. Out of respect and courtesy, why not do in a
>>> branch if the downside costs of having to bring it back to trunk are
>>> so low?
>>
>> If there are differences they should be aired on this list. I see
>> this as a back channel to not have Aaron implement a feature everyone
>> liked except Jeremy.
>
> They are being aired on the list. Doing the code in a branch (which
> seems to have no real extra cost) is also as transparent as can be.
> With no added work, with everything in public, how is this a "back
> channel", and how would this prevent, discourage or otherwise
> influence Aaron to not implement anything he wishes?
>
>>
>>> It's rather traditional in some other projects I've been in to
>>> demonstrate contrary ideas in a way that guarantees good exposure to
>>> the community, with little disruption.
>>
>> For a stable project that is not under active development, I
>> understand, but everything in geronimo is changing quickly. Should I
>> have implemented disabled gbeans in another branch? Should Alan
>> implement CORBA in a branch? Since this is the first time for
>> someone to branch, I suspicious of the motivations.
>
> You might then suggest what my motivations would be for trying to
> diffuse this in a way that everything can be done in the open.
>
> geir
>
>>
>> -dain
>>
>>
> --
> Geir Magnusson Jr +1-203-665-6437
> geir@gluecode.com
Re: SVN Branches
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Nov 4, 2004, at 4:09 PM, Dain Sundstrom wrote:
> On Nov 4, 2004, at 3:51 PM, Geir Magnusson Jr wrote:
>
>>
>> On Nov 4, 2004, at 3:45 PM, Dain Sundstrom wrote:
>>
>>> It is covered in the subversion book http://svnbook.red-bean.com/
>>>
>>> Can understand why you would want to branch for security, but I
>>> think you should keep working on your deployment stuff in the main
>>> trunk.
>>
>> If it's easy to fold back in, why not do in a branch? There's
>> clearly a difference of opinion here, one in which both sides feel
>> pretty strongly. Out of respect and courtesy, why not do in a branch
>> if the downside costs of having to bring it back to trunk are so low?
>
> If there are differences they should be aired on this list. I see
> this as a back channel to not have Aaron implement a feature everyone
> liked except Jeremy.
They are being aired on the list. Doing the code in a branch (which
seems to have no real extra cost) is also as transparent as can be.
With no added work, with everything in public, how is this a "back
channel", and how would this prevent, discourage or otherwise influence
Aaron to not implement anything he wishes?
>
>> It's rather traditional in some other projects I've been in to
>> demonstrate contrary ideas in a way that guarantees good exposure to
>> the community, with little disruption.
>
> For a stable project that is not under active development, I
> understand, but everything in geronimo is changing quickly. Should I
> have implemented disabled gbeans in another branch? Should Alan
> implement CORBA in a branch? Since this is the first time for someone
> to branch, I suspicious of the motivations.
You might then suggest what my motivations would be for trying to
diffuse this in a way that everything can be done in the open.
geir
>
> -dain
>
>
--
Geir Magnusson Jr +1-203-665-6437
geir@gluecode.com
Re: SVN Branches
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Nov 4, 2004, at 3:51 PM, Geir Magnusson Jr wrote:
>
> On Nov 4, 2004, at 3:45 PM, Dain Sundstrom wrote:
>
>> It is covered in the subversion book http://svnbook.red-bean.com/
>>
>> Can understand why you would want to branch for security, but I think
>> you should keep working on your deployment stuff in the main trunk.
>
> If it's easy to fold back in, why not do in a branch? There's clearly
> a difference of opinion here, one in which both sides feel pretty
> strongly. Out of respect and courtesy, why not do in a branch if the
> downside costs of having to bring it back to trunk are so low?
If there are differences they should be aired on this list. I see this
as a back channel to not have Aaron implement a feature everyone liked
except Jeremy.
> It's rather traditional in some other projects I've been in to
> demonstrate contrary ideas in a way that guarantees good exposure to
> the community, with little disruption.
For a stable project that is not under active development, I
understand, but everything in geronimo is changing quickly. Should I
have implemented disabled gbeans in another branch? Should Alan
implement CORBA in a branch? Since this is the first time for someone
to branch, I suspicious of the motivations.
-dain
Re: SVN Branches
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Nov 4, 2004, at 3:45 PM, Dain Sundstrom wrote:
> It is covered in the subversion book http://svnbook.red-bean.com/
>
> Can understand why you would want to branch for security, but I think
> you should keep working on your deployment stuff in the main trunk.
If it's easy to fold back in, why not do in a branch? There's clearly
a difference of opinion here, one in which both sides feel pretty
strongly. Out of respect and courtesy, why not do in a branch if the
downside costs of having to bring it back to trunk are so low?
It's rather traditional in some other projects I've been in to
demonstrate contrary ideas in a way that guarantees good exposure to
the community, with little disruption.
geir
>
> -dain
>
> --
> Dain Sundstrom
> Chief Architect
> Gluecode Software
> 310.536.8355, ext. 26
>
> On Nov 4, 2004, at 3:11 PM, Aaron Mulder wrote:
>
>> Is there a way to branch a few files or directories and leave the
>> rest of the server tracking with the trunk?
>>
>> For example, if I wanted to branch security or deployment, in such
>> a way that you could check out my branch and get the most current
>> versions
>> of everything, except my versions of security or deployment.
>>
>> The best I've heard is to branch everything, apply my changes, and
>> then continually merge changes from trunk to branch. This has 2
>> problems:
>>
>> 1) I have to keep track of the last trunk rev I merged to the branch
>> so
>> that next time I can only merge from that point to the current rev
>>
>> 2) I have to resolve conflicts in my branched code, if there were any
>> trunk changes to that
>>
>> Thanks,
>> Aaron
>
>
--
Geir Magnusson Jr +1-203-665-6437
geir@gluecode.com
Re: SVN Branches
Posted by Dain Sundstrom <ds...@gluecode.com>.
It is covered in the subversion book http://svnbook.red-bean.com/
Can understand why you would want to branch for security, but I think
you should keep working on your deployment stuff in the main trunk.
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26
On Nov 4, 2004, at 3:11 PM, Aaron Mulder wrote:
> Is there a way to branch a few files or directories and leave the
> rest of the server tracking with the trunk?
>
> For example, if I wanted to branch security or deployment, in such
> a way that you could check out my branch and get the most current
> versions
> of everything, except my versions of security or deployment.
>
> The best I've heard is to branch everything, apply my changes, and
> then continually merge changes from trunk to branch. This has 2
> problems:
>
> 1) I have to keep track of the last trunk rev I merged to the branch so
> that next time I can only merge from that point to the current rev
>
> 2) I have to resolve conflicts in my branched code, if there were any
> trunk changes to that
>
> Thanks,
> Aaron