[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Do trivial conflicts in backports require temporary branches?

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 24 Mar 2008 00:16:50 +0100

I'd like to nominate r30004 for backport to 1.4.x.

See here for a 1.4.x user being bitten by the issue:
http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=76142

In case we ever have another 1.4.x release, it would be
bad if it did not fix this bug.

According to both Erik Hülsmann and the Hacker's guide,
a backport that causes a conflict needs a temporary branch.

Merging r30004 (which changes a single file) into 1.4.x does cause
one conflict, but it is really, really, trivial (whitespace changes).

Should I create a temporary branch nonetheless?

#ifdef MAX_SECS_TO_LINGER
      /* ### old APR interface */
      status = apr_socket_create(sock, sa->family, SOCK_STREAM, pool);
#else
<<<<<<< .working
  status = apr_socket_create(sock, sa->family, SOCK_STREAM, APR_PROTO_TCP,
                             pool);
=======
      status = apr_socket_create(sock, sa->family, SOCK_STREAM, APR_PROTO_TCP,
                                 pool);
>>>>>>> .merge-right.r30004
#endif
      if (status == APR_SUCCESS)
        {

P.S. I've already nominated r30004 for backport to 1.5.x, without
testing the merge beforehand (sorry, will never happen again).
Turns out it doesn't cause a conflict while merging into 1.5.x :)

-- 
Stefan Sperling <stsp_at_elego.de>                 Software Developer
elego Software Solutions GmbH                            HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12        Tel:  +49 30 23 45 86 96 
13355 Berlin                              Fax:  +49 30 23 45 86 95
http://www.elego.de                 Geschaeftsfuehrer: Olaf Wagner

  • application/pgp-signature attachment: stored
Received on 2008-03-24 01:17:00 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.