On 1/31/13 12:08 PM, Stefan Sperling wrote:
On Thu, Jan 31, 2013 at 10:37:14AM -0500, Alfred Perlstein wrote:
FreeBSD has moved to Subversion a few years ago and it's worked
very, very well for us.
Thanks! That's encouraging to hear.
The one area where we are having issues is merging code from project
branches back into trunk.
The typical workflow is:
1) create project branch.
2) code code code.
3) sync from HEAD (this works great).
4) repeat steps 2+3 until feature is complete.
5) svn diff and apply to head then commit.
Is there a way to do 5 automatically?
I think the worry is mergeinfo from the project branch coming back
into HEAD.
Any tips would be appreciated.
I've read the FreeBSD svn merging docs some time ago. I'm not sure if
changes have been made since, but it was probably an older version
of what currently lives at this URL:
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/subversion-primer.html
Back then I was somewhat worried that apparently the person who wrote them
didn't really understand much about how merges in Subversion work.
There was irrational fear of mergeinfo propagation, to the point where
the recommended practice is to remove mergeinfo before commit, which
any Subversion user with a clue will know is very wrong (expect in very
exceptional circumstances and only if you are equipped with sufficient
expertise to deal with the consequences).
What surprised me also was a complete lack of mention of the --reintegrate
option, which I suspect must be causing quite a lot of grief among FreeBSD
developers due to bogus conflicts during merges back into FreeBSD's head
branch (i.e. the trunk).
We'll need more details to help you in a constructive way, though.
Can you provide more details about your steps 1 to 5, i.e. show the
exact commands you're running in each step? The repository is public,
after all, which will help greatly with identifying and reproducing
specific problems.
I'm happy to provide input for improving FreeBSD's docs to the point
where FreeBSD makes the best possible use of Subversion 1.7's merge
implementation, and can also provide some hints as to how future versions
of Subversion will improve to make life easier in certain cases.
BTW, I went over one of FreeBSD's svn wiki pages a while back, and added
answers to open questions on this page:
https://wiki.freebsd.org/SubversionMissing
Thank you Stefan,
So I have two answers here:
1) about mergeinfo
It seems as if doing it all at the top can make merges over long haul
internet very painful.
2) about reintegrate
I've attached the two messages that show what makes FreeBSD gun shy
about merges to HEAD.
Maybe these issues are resolved, or maybe the developer did something
incorrect, or maybe something else entirely different happened.
See attached.
Thank you,
-Alfred
--- Begin Message ---
--
John Baldwin
--- Begin Message ---
On Friday, June 01, 2012 1:40:29 pm David O'Brien wrote:
> On Wed, May 16, 2012 at 11:00:48AM -0400, John Baldwin wrote:
> > I more or less don't trust svn merge to DTRT here. This was done with
> > the cpuset branch merge up to HEAD and it broke the log history of many
> > files in HEAD.
>
> Specifically how did it break log history?
http://svnweb.freebsd.org/base/head/share/man/man4/geom_map.4?view=log
You have to walk up to the previous directory in svnweb and go back to
change 222812 and then click on geom_map.4 to find its original log.
sys/dev/iicbus/ad7417.c was also busted this way.
> > I would just generate a diff and manually apply that to
> > a HEAD checkout and commit that. You could perhaps svn cp over new files
> > from the nand branch to HEAD to preserve their history, but I worry that
> > anything other than diff + patch for existing files risks hosing history.
>
> WOAH!! Please lets gain some new experience with 'svn merge' using
> version 1.7. We do 100's of merges a year at $WORK (with svn 1.6)
> on a code base 10x that of FreeBSD -- it works.
I've never had problems with merging downstream into work branches. I've
only seen upstream merges blow up.
--
John Baldwin
--
This mail is for the internal use of the FreeBSD project committers,
and as such is private. This mail may not be published or forwarded
outside the FreeBSD committers' group or disclosed to other unauthorised
parties without the explicit permission of the author(s).
--- End Message ---
--- End Message ---
--- Begin Message ---
On Friday, February 01, 2013 7:53:57 am Alfred Perlstein wrote:
> John and Peter, both of you are +inf more knowledgeable about svn than I am.
>
> I see we still try to minimize svn mergeinfo from the FAQ ("Selecting
> the Source and Target")
> http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-
guide/subversion-primer.html#AEN771
>
> I know I've seen some emails explaining the reasoning behind this but I
> can't find them. What would the effect of bringing mergeinfo to the top be?
>
> Possible problems:
> 1) it would get very large
> 2) if we ever were to split up the repo it would be a problem.
> 3) ... ?
It makes merges from across the continental US take a long time.
> Additionally, what are our concerns about the --reintegrate option
> (which was added (or at least improved) after we switched)
It trashes history if SVN mucks it up (and it can). This has already happened
at least once, and I've noted that in a thread on developers.
I've forwarded you the relevant mail from that thread.
--
John Baldwin
--- End Message ---
