Client certificate authentication fails with SVN and OpenSSL 1.0.1

[gadamiak]

My Subversion repositories running under Apache 2.2.22 on Ubuntu Server 
12.04 amd64 can't be accessed any more with TortoiseSVN above 1.7.6 when 
client certificate authentication is required. The same happens when using 
CLI client (svn 1.7.5) shipped with TortoiseSVN.

I described the issue in detail on openssl mailing list, so I won't 
duplicate it here and provide a link instead: 
https://groups.google.com/d/topic/mailing.openssl.users/reexAMqsre8/discussion

There have been a few reports on TSVN list too but no resolution so far. 
Any clues?

Ancestrally Related Error Message

[C M]

Hello,

Code for a new development effort was imported into a developer’s branch.

Now we want merge his changes to trunk (which is currently empty).

I tried the merge from both the command line and the Tortoise GUI and keep
running into the “…must be ancestrally related…” message.I also tried the
"ignore ancestry" option via the GUI.

One, I don't understand why SVN thinks there is even an ancestral
relationship betweeen the two locations?

Two, how can I do to get around this error message?


Amad

RE: Ancestrally Related Error Message

[Bob Archer]

> Hello,
> Code for a new development effort was imported into a developer's branch.
> Now we want merge his changes to trunk (which is currently empty).
> I tried the merge from both the command line and the Tortoise GUI and keep
> running into the "...must be ancestrally related..." message.I also tried the
> "ignore ancestry" option via the GUI.
> One, I don't understand why SVN thinks there is even an ancestral relationship
> betweeen the two locations?
> Two, how can I do to get around this error message?
> 

>From your message I assume that your "branch" install a copy of your trunk, 
>hence not "ancestrally related". 

It "thinks" there is a relationship because you are doing a merge. I'm not sure 
why the "ignore ancestry" doesn't solve the issue though. 

Since trunk is empty... why not just delete trunk and copy that branch to trunk?

BOb

Re: Ancestrally Related Error Message

[C. Michael Pilato]

On 06/17/2013 11:19 AM, C M wrote:
> Hello,
> 
> Code for a new development effort was imported into a developer’s branch.
> 
> Now we want merge his changes to trunk (which is currently empty).
> 
> I tried the merge from both the command line and the Tortoise GUI and keep
> running into the “…must be ancestrally related…” message.I also tried the
> "ignore ancestry" option via the GUI.
> 
> One, I don't understand why SVN thinks there is even an ancestral
> relationship betweeen the two locations?

Subversion doesn't think there is.  Rather, it knows there isn't.  Hence the
message.  The error was introduced to prevent a common mistake folks make
when they misalign their merge sources and targets:

   $ svn merge ^/trunk branches
   ^C^C^Cdangit i meant to type "branches/my-branch"^C^Cagh!

> Two, how can I do to get around this error message?

Well... the --ignore-ancestry option was *supposed* to make that happen for
you.  Perhaps there's a bug?

You may need to give a more complete transcript of what you're trying,
including command-line examples and such.

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development



signature.asc
Description: OpenPGP digital signature

Re: Ancestrally Related Error Message

[C M]

I think my earlier mistake might have been that I was using the
--reintegrate option.
Without it, I make some progress, but still not quite what I am expecting.

Again, given that trunk is empty, why the "C" (tree conflicts)? I would
expect all of then to be "A" (additions), no?

The DEV_WC currently only shows the two dirs which SVN correctly recognized
as additions.

c:\Temp\DEV_WC>svn merge --dry-run --ignore-ancestry
https://path_to_branch/SCR_BR/

--- Merging r1191 through r1245 into '.':
   C ini
   C txt
   C graphics
   C MMI
   C backups
   C sysctrl
Asysconfig
Asysconfig\src
Asysconfig\src\sysconfig
Asysconfig\src\sysconfig.c
Asysconfig\src\sysconfig_init.c
Asysconfig\src\log
Asysconfig\src\makefile
Asysconfig\inc

   C cpu
Amtl
Amtl\lib
Amtl\lib\mtl.lib
Amtl\src
Amtl\src\mtl_meter.c
Amtl\src\mtl
Amtl\src\makefile
Amtl\src\mtl.c
Amtl\inc
Amtl\inc\mtl_meter.h
   C util_panel
 U   .
Summary of conflicts:
  Tree conflicts: 8


On Mon, Jun 17, 2013 at 10:38 AM, C. Michael Pilato wrote:

> On 06/17/2013 11:19 AM, C M wrote:
> > Hello,
> >
> > Code for a new development effort was imported into a developer’s branch.
> >
> > Now we want merge his changes to trunk (which is currently empty).
> >
> > I tried the merge from both the command line and the Tortoise GUI and
> keep
> > running into the “…must be ancestrally related…” message.I also tried the
> > "ignore ancestry" option via the GUI.
> >
> > One, I don't understand why SVN thinks there is even an ancestral
> > relationship betweeen the two locations?
>
> Subversion doesn't think there is.  Rather, it knows there isn't.  Hence
> the
> message.  The error was introduced to prevent a common mistake folks make
> when they misalign their merge sources and targets:
>
>$ svn merge ^/trunk branches
>^C^C^Cdangit i meant to type "branches/my-branch"^C^Cagh!
>
> > Two, how can I do to get around this error message?
>
> Well... the --ignore-ancestry option was *supposed* to make that happen for
> you.  Perhaps there's a bug?
>
> You may need to give a more complete transcript of what you're trying,
> including command-line examples and such.
>
> --
> C. Michael Pilato 
> CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development
>
>

RE: Ancestrally Related Error Message

[Bob Archer]

Did you try it without using Dry Run... I have found at times that can cause 
issues. There's really no need to use dry run since you can just revert. Just 
make sure you have no pending changes in your target working copy.

From: C M [mailto:cmanalys...@gmail.com]
Sent: Monday, June 17, 2013 12:39 PM
To: C. Michael Pilato
Cc: Subversion
Subject: Re: Ancestrally Related Error Message

I think my earlier mistake might have been that I was using the --reintegrate 
option.
Without it, I make some progress, but still not quite what I am expecting.
Again, given that trunk is empty, why the "C" (tree conflicts)? I would expect 
all of then to be "A" (additions), no?
The DEV_WC currently only shows the two dirs which SVN correctly recognized as 
additions.

c:\Temp\DEV_WC>svn merge --dry-run --ignore-ancestry 
https://path_to_branch/SCR_BR/

--- Merging r1191 through r1245 into '.':
   C ini
   C txt
   C graphics
   C MMI
   C backups
   C sysctrl
Asysconfig
Asysconfig\src
Asysconfig\src\sysconfig
Asysconfig\src\sysconfig.c
Asysconfig\src\sysconfig_init.c
Asysconfig\src\log
Asysconfig\src\makefile
Asysconfig\inc

   C cpu
Amtl
Amtl\lib
Amtl\lib\mtl.lib
Amtl\src
Amtl\src\mtl_meter.c
Amtl\src\mtl
Amtl\src\makefile
Amtl\src\mtl.c
Amtl\inc
Amtl\inc\mtl_meter.h
   C util_panel
 U   .
Summary of conflicts:
  Tree conflicts: 8

On Mon, Jun 17, 2013 at 10:38 AM, C. Michael Pilato 
mailto:cmpil...@collab.net>> wrote:
On 06/17/2013 11:19 AM, C M wrote:
> Hello,
>
> Code for a new development effort was imported into a developer's branch.
>
> Now we want merge his changes to trunk (which is currently empty).
>
> I tried the merge from both the command line and the Tortoise GUI and keep
> running into the "...must be ancestrally related..." message.I also tried the
> "ignore ancestry" option via the GUI.
>
> One, I don't understand why SVN thinks there is even an ancestral
> relationship betweeen the two locations?
Subversion doesn't think there is.  Rather, it knows there isn't.  Hence the
message.  The error was introduced to prevent a common mistake folks make
when they misalign their merge sources and targets:

   $ svn merge ^/trunk branches
   ^C^C^Cdangit i meant to type "branches/my-branch"^C^Cagh!

> Two, how can I do to get around this error message?
Well... the --ignore-ancestry option was *supposed* to make that happen for
you.  Perhaps there's a bug?

You may need to give a more complete transcript of what you're trying,
including command-line examples and such.

--
C. Michael Pilato mailto:cmpil...@collab.net>>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud 
Development

Re: Ancestrally Related Error Message

[C. Michael Pilato]

On 06/17/2013 12:39 PM, C M wrote:
> I think my earlier mistake might have been that I was using the
> --reintegrate option.
> Without it, I make some progress, but still not quite what I am expecting.
> 
> Again, given that trunk is empty, why the "C" (tree conflicts)? I would
> expect all of then to be "A" (additions), no?
> 
> The DEV_WC currently only shows the two dirs which SVN correctly recognized
> as additions.
> 
> c:\Temp\DEV_WC>svn merge --dry-run --ignore-ancestry
> https://path_to_branch/SCR_BR/
> 
> --- Merging r1191 through r1245 into '.':

Do these revision numbers (r1191 and r1245) match what you'd expect?  What
happens if you do this:

   svn diff -r1190:1245 https://path_to_branch/SCR_BR/

Do you see exactly the additions that you would expect to see?

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development



signature.asc
Description: OpenPGP digital signature

Re: Ancestrally Related Error Message

[C M]

Running without the dry-run option doesn't do anything different (it still
reports the conflicts). Yes, the diff shows the content I am expecting (at
least for the text files).

I ran "svn diff -r1190:1245 --summarize https://path_to_branch/SCR_BR/"; and
see output like:

M path_to_file
M path_to_file
M path_to_file

Without the "--summarize" option, I see the file content which matches what
we are expecting. This is for the text files which SVN identified as being
conflicted.

I have several developer branches to merge to trunk. If I can't get the
merge to work, is doing a copy from the branch to trunk an option? Will
that create further issues downstream? I know no one has a crystal ball,
but I have limited experience with SVN and dont know what to expect.




See example below

=
--- txt/pod_block.txt   (revision 1190)
+++ txt/pod_block.txt   (revision 1245)
@@ -1,7 +1,7 @@


On Mon, Jun 17, 2013 at 11:56 AM, C. Michael Pilato wrote:

> On 06/17/2013 12:39 PM, C M wrote:
> > I think my earlier mistake might have been that I was using the
> > --reintegrate option.
> > Without it, I make some progress, but still not quite what I am
> expecting.
> >
> > Again, given that trunk is empty, why the "C" (tree conflicts)? I would
> > expect all of then to be "A" (additions), no?
> >
> > The DEV_WC currently only shows the two dirs which SVN correctly
> recognized
> > as additions.
> >
> > c:\Temp\DEV_WC>svn merge --dry-run --ignore-ancestry
> > https://path_to_branch/SCR_BR/
> >
> > --- Merging r1191 through r1245 into '.':
>
> Do these revision numbers (r1191 and r1245) match what you'd expect?  What
> happens if you do this:
>
>svn diff -r1190:1245 https://path_to_branch/SCR_BR/
>
> Do you see exactly the additions that you would expect to see?
>
> --
> C. Michael Pilato 
> CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development
>
>

RE: Ancestrally Related Error Message

[Andrew Reedick]

> From: C M [mailto:cmanalys...@gmail.com] 
> Sent: Monday, June 17, 2013 12:39 PM
> To: C. Michael Pilato
> Cc: Subversion
> Subject: Re: Ancestrally Related Error Message
>
> I think my earlier mistake might have been that I was using the --reintegrate 
> option. 
> Without it, I make some progress, but still not quite what I am expecting.
> Again, given that trunk is empty, why the "C" (tree conflicts)? I would 
> expect all of then to be "A" (additions), no?
> The DEV_WC currently only shows the two dirs which SVN correctly recognized 
> as additions.
>
> c:\Temp\DEV_WC>svn merge --dry-run --ignore-ancestry 
> https://path_to_branch/SCR_BR/
>
> --- Merging r1191 through r1245 into '.':
>   C ini
>   C txt
>   C graphics
>   C MMI
>   C backups
>   C sysctrl

>   C cpu
> A    mtl
> Summary of conflicts:
>   Tree conflicts: 8

What kind of tree conflicts are they?  'svn status' should provide more detail. 
 Also, what version of svn are you using?  1.6? 1.7?

Why is trunk empty?  Because you deleted trunk after the branch was created? 
(i.e. create branch, delete trunk/*, merge from branch.)

I get the vague feeling that you have 'incoming add after delete'(?) type 
messages on the directory conflicts.

 

Re: Ancestrally Related Error Message

[C M]

We are on SVN 1.7.6.

Trunk is empty because this is/was a new development effort. The code was
directly imported into the developer's branch.

I ran these two commans in the working copy and get the messages you
mentioned. What does that mean?

c:\Temp\DEV_WC>svn merge --dry-run --revision 1190:1233
c:\Temp\DEV_WC>svn status
 M  .
! C MMI
  >   local delete, incoming edit upon merge
! C graphics
  >   local delete, incoming edit upon merge
! C hpu
  >   local delete, incoming edit upon merge
! C ini
  >   local delete, incoming edit upon merge
! C misc.backups
  >   local delete, incoming edit upon merge
A  +mtl
A  +sysconfig
! C sysctrl
  >   local delete, incoming edit upon merge
! C txt
  >   local delete, incoming edit upon merge
! C util_panel
  >   local delete, incoming edit upon merge
Summary of conflicts:
  Tree conflicts: 8


On Mon, Jun 17, 2013 at 12:40 PM, Andrew Reedick  wrote:

>
>
> > From: C M [mailto:cmanalys...@gmail.com]
> > Sent: Monday, June 17, 2013 12:39 PM
> > To: C. Michael Pilato
> > Cc: Subversion
> > Subject: Re: Ancestrally Related Error Message
> >
> > I think my earlier mistake might have been that I was using the
> --reintegrate option.
> > Without it, I make some progress, but still not quite what I am
> expecting.
> > Again, given that trunk is empty, why the "C" (tree conflicts)? I would
> expect all of then to be "A" (additions), no?
> > The DEV_WC currently only shows the two dirs which SVN correctly
> recognized as additions.
> >
> > c:\Temp\DEV_WC>svn merge --dry-run --ignore-ancestry
> https://path_to_branch/SCR_BR/
> >
> > --- Merging r1191 through r1245 into '.':
> >   C ini
> >   C txt
> >   C graphics
> >   C MMI
> >   C backups
> >   C sysctrl
>
> >   C cpu
> > Amtl
> > Summary of conflicts:
> >   Tree conflicts: 8
>
> What kind of tree conflicts are they?  'svn status' should provide more
> detail.  Also, what version of svn are you using?  1.6? 1.7?
>
> Why is trunk empty?  Because you deleted trunk after the branch was
> created? (i.e. create branch, delete trunk/*, merge from branch.)
>
> I get the vague feeling that you have 'incoming add after delete'(?) type
> messages on the directory conflicts.
>
>
>
>

Re: Ancestrally Related Error Message

[Les Mikesell]

On Mon, Jun 17, 2013 at 12:59 PM, C M  wrote:
> We are on SVN 1.7.6.
>
> Trunk is empty because this is/was a new development effort. The code was
> directly imported into the developer's branch.
>
> I ran these two commans in the working copy and get the messages you
> mentioned. What does that mean?
>
> c:\Temp\DEV_WC>svn merge --dry-run --revision 1190:1233
> c:\Temp\DEV_WC>svn status
>  M  .
> ! C MMI
>   >   local delete, incoming edit upon merge
[...]

And you are merging into a working copy that is a checkout of the
empty trunk?   Anyway if the trunk is empty you should get the same
result if you just copy the branch to it.

--
   Les Mikesell
 lesmikes...@gmail.com

Re: Ancestrally Related Error Message

[C M]

Well, for what its worth, I was able to complete the "merge" following
steps 3 -6 in this article.

http://kirenpillay.blogspot.com/2012/07/svn-merge-tree-conflict-resolution.html

I don't understand why SVN behaved the way it did and prevented the branch
to trunk merge as expected..





On Mon, Jun 17, 2013 at 1:47 PM, Les Mikesell  wrote:

> On Mon, Jun 17, 2013 at 12:59 PM, C M  wrote:
> > We are on SVN 1.7.6.
> >
> > Trunk is empty because this is/was a new development effort. The code was
> > directly imported into the developer's branch.
> >
> > I ran these two commans in the working copy and get the messages you
> > mentioned. What does that mean?
> >
> > c:\Temp\DEV_WC>svn merge --dry-run --revision 1190:1233
> > c:\Temp\DEV_WC>svn status
> >  M  .
> > ! C MMI
> >   >   local delete, incoming edit upon merge
> [...]
>
> And you are merging into a working copy that is a checkout of the
> empty trunk?   Anyway if the trunk is empty you should get the same
> result if you just copy the branch to it.
>
> --
>Les Mikesell
>  lesmikes...@gmail.com
>

Re: History in subversion

[Olivier Antoine]

Hi,


>>> From: Ryan Schmidt

> On the other hand, let's say you've made changes and tested them and try
to commit and it fails because a file is out of date.
> You wish you had made a feature branch for these changes. No problem; you
can still do it now.
> Use "svn info" on the working copy to find out what revision of trunk you
had checked out. Let's say it was 1234.
> Make a feature branch in the repository from that revision of trunk ("svn
cp $REPO/trunk@1234 $REPO/branches/my-feature-branch").
> Switch the working copy to that branch ("svn sw
$REPO/branches/my-feature-branch"). Commit the changes; it'll succeed.
> Now you have the state of the software you developed recorded in the
repository in the feature branch.
> Now you can continue with the task of reintegrating the feature branch
into trunk using "svn merge".

Very smart, and that seems so easy.
With CC, I'm used to create branch when the work starts, not when it is
done.
This is nice.


>>> From: Les Mikesell

> The common scenario is to have multiple 'projects' under the same
> repository root, each with their own trunk/branches/tags tree.

To be honest, I'm afraid of several projects sharing a same revision
numbering.
Repository gets bigger and bigger, problems with disk space arise, one
project wants to leave the repo,
but there is not enough space even to run svn+dump, finally a new repo is
created for the project (and the project asks to remove empty revisions ...
!).
I would prefer to create one repo per project, with one triplet of
directories trunk+branches+tags.


> Once you have copied it, it goes its own way but retains previous history
- there is nothing wrong with that.
> Consider a library that evolves as a component of some other project,
> but you subsequently realize it can be used in several programs that will
be maintained separately.
> It might make sense to copy it up to its own top-level project
> where it can more sensibly have its own release schedule with its own
branches and tags
> to easily support multiple versions concurrently being used by different
things.

Yes, I agree.
This copy mechanism, used in a raisonnable way, can be useful.

What is still confusing for me is to see that svn+annotate contains the
previous history.
Even if it is the same principle with CC for an element that is moved or
renamed.
So this is just new for me.

> So I guess you'd have to branch in the repository to match what svn does
with working copies.

Branches to isolate, or continuous integration to watch regression.

> You can use hook scripts for that.
> We sometimes check out source from tags and commit the resulting binaries
back
>  - not exactly 'clean' but pragmatically useful - and possible with an
appropriate script
> that allows this exception.

Hum ... are these scripts "downloadable" somewhere, or do we have to write
them ... ?

> If you want to store all copies of concurrent work instead of just the
> the way you resolved your updates, you need to be working on separate
> branches with later resolution.   That's the 'feature branch' style
> and there are sometimes reasons to use it, even though there is some
> extra overhead.   But regardless of the process, you eventually have
> to resolve conflicting changes.

Yes, this is the solution. In CC, there is the same problem.

Thanks !

>

Re: History in subversion

[Les Mikesell]

On Mon, Jun 17, 2013 at 4:09 PM, Olivier Antoine
 wrote:
>
>> The common scenario is to have multiple 'projects' under the same
>> repository root, each with their own trunk/branches/tags tree.
>
> To be honest, I'm afraid of several projects sharing a same revision
> numbering.
> Repository gets bigger and bigger, problems with disk space arise, one
> project wants to leave the repo,
> but there is not enough space even to run svn+dump, finally a new repo is
> created for the project (and the project asks to remove empty revisions ...
> !).
> I would prefer to create one repo per project, with one triplet of
> directories trunk+branches+tags.

That's a reasonable choice - and with a repo approaching 80GB I
understand the issue although it has not been an actual problem yet.
However, other than the sheer size of the dump/filter operation,
extracting a portion should be practical even if you renumber as long
as you have made tags and use those human-friendly tag names for
externals and other specific revisions you need to reference
consistently instead of peg revision numbers.

>
>> You can use hook scripts for that.
>> We sometimes check out source from tags and commit the resulting binaries
>> back
>>  - not exactly 'clean' but pragmatically useful - and possible with an
>> appropriate script
>> that allows this exception.
>
> Hum ... are these scripts "downloadable" somewhere, or do we have to write
> them ... ?

Various versions have been posted to forums - and are fairly easy to
find with a google search.   I'm not sure if there is an 'official'
collection anywhere.

--
   Les Mikesell
 lesmikes...@gmail.com