Hello there (and congrats for the release !),
I was about to directly file a bug but finally decided to go through the proper process...
As we are planning to move from 1.7 to 1.8, we already migrated a few clients
(not yet the server), and the following change, as I suspected, hit us:
* reject some attempts to merge between unrelated branches (r1215273)
Previous sync merges which were accepted in 1.7 are now forbidden in 1.8,
and there is no way to bypass the check.
With a 1.8 client (still on a 1.7 server), we now have errors like:
svn: E205000: Try 'svn help merge' for more information
svn: E205000: Source and target must be different but related branches
svn: E205000: Source and target have no common ancestor: 'svn://myserver/app/v1_at_head' and '._at_unspecified'
(Whereas the sync merge worked flawlessly with all 1.7 clients, with proper merge tracking).
I tried with --ignore-ancestry and/or --force options, without much success.
The only work-around was to perform the merge from a 1.7 client.
Of course the layout of the repository is historical and a bit complex;
I'll try to represent it here: (hoping you have a fixed font...)
/app/v2-dev /------------------
/app/v2-candidate /---/-------------------
/app/v2-stable /---/------------------------
/v2 /------/ (no more used)
/app/v3-dev / /---------------------
/app/v3-candidate / /---/----------------------
/app/v3-stable / /--/---------------------------
/ /
/app/trunk / /-----/--------------------------------
/trunk ---/--/ (no more used)
(largely eluded: less versions, no feature branches, etc.)
The sync merges which no more works are like:
/app/v2-dev => /app/v3-dev
As you can see, none is a direct ancestor of the other, but they share
a common one: /trunk (despite renamed as /app/trunk).
And this has been working perfectly with 1.7 for months, so we'd like to keep
she same process once we upgrade both the server and the clients to 1.8.
Few questions:
- How do you define unrelated branches ? For me v2-dev and v3-dev are related...
- Is this, as I suspect, a real bug/regression of r1215273, or are we out-of-spec ?
- If I should file a bug, do you need more infos ?
I really don't think that detailed compiler options are needed,
but I may provide a test script reproducing the issue.
If you need a better overview of our process, here are a few details:
Each supported version (v2 and v3) has 3 dedicated branches:
-stable is the official latest release version. Only urgent hotfixes are done here.
-candidate is for internal testing (by QA). Only regressions are fixed.
Once fully tested/validated, it is reintegrated into -stable for release (and revived with a record-only)
-dev is for daily work, non-urgent fixes, features development (through branches).
On beginning of cycles, it is reintegrated into -candidate (and revived with a record-only)
Hotfixes (from -stable) and regression fixes (from -candidate) are immediately
propagated upwards (to -candidate and -dev branches) so they also get tested by
all developers.
Changes from v2-dev are regularly propagated to v3-dev;
so are those from v3-dev to trunk.
Environment:
- server: debian 1.7.9-1+nmu1 (amd64)
- client: debian 1.8.0-1+WANdisco (amd64)
Sincerely
--
Eric
Received on 2013-07-05 23:54:13 CEST