geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: SVN Branches
Date Fri, 05 Nov 2004 01:32:47 GMT
	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
> 
> 

Mime
View raw message