Re: SVN in Z-LINUX

[shrinivasan]

On Saturday 20 August 2011 07:35 AM, dvia...@proderj.rj.gov.br wrote:

Hi,

We use SVN in intel paltform, with Debian (Ubuntu).
We intend to use it in mainframe Z-LINUX / redhat (with Z-VM archteture ).
Can we go on, or it´s just kown that it will not work ?




You can download the source from
http://subversion.apache.org/download/

and compile for z-linux.

It will work as usual.

Regards,
Shrinivasan

Single-commit import with properties and SVN 1.7

[Markus Schaber]

Hi,

We need to add a new directory including files and properties to a
subversion repository "in-place".

With SVN 1.6, the following did work: (I know that this is only an
artifact and was no documented / intended behavior.)
- Checkout the parent directory to a temporary place.
- create and svn add the data directory under the parent working copy.
- svn add and svn propset all the children we need in the working copy.
- svn commit the parent directory (to add everything in a single
commit.)
- move the data directory to the intended working copy place.
- delete the temporary parent directory.

With SVN 1.7, I only see a way to do this with 2 commits:
- svn remote add the data directory. (First commit)
- checkout the data directory
- fill the data directory with contents (files and properties)
- svn commit the data directory. (Second commit).
(This is analogeous to the "in-place import" in the FAQ.)

Is it theoretically possible with the new working copy architecture to
allow the working copy root itself to be "scheduled for addition"?

This could be the base for a nice feature for SVN 1.8, allowing both
"in-place import" and "import with properties", maybe some command like
"svn checkout --for-addition
svn://destination/url/to/some/non/existing/directory/with/existing/paren
t".



Best regards

Markus Schaber

___
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 |
Fax +49-831-54031-50

Email: m.scha...@3s-software.com | Web: http://www.3s-software.com 
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects:
http://www.3s-software.com/index.shtml?sample_projects

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 

AW: SVN in Z-LINUX

[Markus Schaber]

Hi, Dayse,

Von: dvia...@proderj.rj.gov.br [mailto:dvia...@proderj.rj.gov.br] 
> We use SVN in intel paltform, with Debian (Ubuntu).
> We intend to use it in mainframe Z-LINUX / redhat (with Z-VM archteture ).
> Can we go on, or it´s just kown that it will not work ?

If there are precompiled SVN binaries for your linux distribution, you can 
assume that it works just fine. (Although some distros ship rather outdated 
packages.)

If there are no precompiled SNV binaries (which I doubt for Redhat), it should 
work by self-compiling the packages and all its dependencies.


Best regards

Markus Schaber

___
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax 
+49-831-54031-50

Email: m.scha...@3s-software.com | Web: http://www.3s-software.com 
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: 
http://www.3s-software.com/index.shtml?sample_projects

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade 
register: Kempten HRB 6186 | Tax ID No.: DE 167014915

Re: Merge symmetry (was: Tree Conflicts with Subversion 1.7)

[Stefan Sperling]

On Fri, Aug 19, 2011 at 04:15:38PM +0200, Andreas Krey wrote:
> On Fri, 19 Aug 2011 13:51:40 +, Stein Somers wrote:
> 
> > Now I realize merges are always asymmetric.
> 
> Actually, merging is a symmetric operation. The tree (and copyfrom
> info) resulting from a merge should be the same independent of in
> which direction the merge is performed.

I agree that symmetry is a nice-to-have property of a merge algorithm.

But I would be totally happy with asymmetric results, as long as either
result is well-defined and repeatable.  I don't see why the behaviour
of a merge algorithm must be symmetric.

> In svn the metadata just looks
> completely different depending on the direction of the merge. (It also
> is different due to the necessity of --reintegrate.)

Sounds like you are conflating the UI with the underlying design.
--reintegrate is a UI issue and has nothing to do with symmetry
or correctness.
See 
http://mail-archives.apache.org/mod_mbox/subversion-dev/201107.mbox/%3c20110720124721.ga7...@ted.stsp.name%3E

Re: Tree Conflicts with Subversion 1.7

[Stefan Sperling]

On Fri, Aug 19, 2011 at 12:20:56PM +0200, Andreas Krey wrote:
> On Thu, 18 Aug 2011 20:46:51 +, Stefan Sperling wrote:
> ...
> > > Actually I think these are better handled by throwing away the merge
> > > results and doing the renames/removes on the respective branches, then
> > > redo the merge.
> > 
> > The above is only for "add vs. add" situations.
> > Scenarios involving renames are different.
> 
> I meant when I get an add/add conflict on unrelated directories
> (or files), I'd undo the merge, rename one of the directories in the
> respective branch and retry the merge.

OK. In this case it should auto-resolve the conflict (it does not as
of now, of course, but it will eventually).

> Offhand, I wouldn't know where
> subversion would place the unrelated versions of the directories in the
> sandbox, nor how I could tell it that I want one of those kept in the
> merge result (with same or different name).

We cannot store the tree anywhere right now.
But we can create some space in the new meta-data store.
 
> > > I tend to feel uneasy in these interactive conflict resolutions.
> > 
> > What makes you feel uneasy about it?
> 
> I'm used to manual merges, which means its always (p) with me. Which
> unfortunately does not work quite well with properties, as far I
> remember.

Can you provide details? What doesn't work, exactly?
Is there already an issue filed for this problem?

> (And (e) gives me 'EDITOR not set' even though it is offered.)

Hmmm... does it not ask for an editor command to run?
That's the least it could do.

> One thing that would be helpful is (!): Run a shell.

I agree that would be nice.

However, right now, svn opens the prompt while the TCP connection
to the server is still open.
We need to change this so that svn first downloads all required data,
and then runs the interactive prompt
(bug: http://subversion.tigris.org/issues/show_bug.cgi?id=3846).
Then we have all time in the world and might as well spawn a shell.

> > Note that, ideally, this menu could be recalled offline, after the
> > merge/update has completed with all conflicts postponed.
> > So you'd have all the time in the world to figure out your answer,
> > if that's what worrying you.
> 
> The problem is more like it is another tool which you hopefully never
> need, yet need to know well if you do.

It's not going to be mandatory. It will be an optional helper,
just like the current interactive conflict resolution prompt.

Proxy authentication with Negotiate uses wrong host

[1983-01-06]

Hi folks,

I am trying to make Subversion run with our ISA proxy which advertises 
Proxy-Authenticate: Negotiate, NTLM, Basic.

My Subversion version is: 1.6.7 on Windows XP, tried with 1.7-beta3 which even 
did not want to accept the URL. The HTTP lib is neon because serf quit working 
with "svn: Error running context: Internal error".
This is the UA sent by Subversion: SVN/1.6.17 (r1128011) neon/0.29.6

Now, when the proxy server challenges Subversion to authenticate, Subversion 
tries to retrieve a service ticket for the target host /instead of/ for the 
proxy host. I debugged that in a Wireshark session.
Should I file a bug report?

I already sent a mail to TortoiseSVN ml [1] but was redirected here because it 
uses Subversion libs to perform authentication.

A very interesting point is that I am running the same setup on FreeBSD and the 
service ticket is successfully obtained for the proxy server.

Mike

[1] 
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2825191


-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!   
Jetzt informieren: http://www.gmx.net/de/go/freephone

Re: Proxy authentication with Negotiate uses wrong host

[Stefan Sperling]

On Mon, Aug 22, 2011 at 12:55:58PM +0200, 1983-01...@gmx.net wrote:
> Hi folks,
> 
> I am trying to make Subversion run with our ISA proxy which advertises 
> Proxy-Authenticate: Negotiate, NTLM, Basic.
> 
> My Subversion version is: 1.6.7 on Windows XP, tried with 1.7-beta3 which 
> even did not want to accept the URL. 

I don't understand what you mean here.
Can you clarify? What error message did you get?

> The HTTP lib is neon because serf quit working with "svn: Error running 
> context: Internal error".
> This is the UA sent by Subversion: SVN/1.6.17 (r1128011) neon/0.29.6
> 
> Now, when the proxy server challenges Subversion to authenticate, Subversion 
> tries to retrieve a service ticket for the target host /instead of/ for the 
> proxy host. I debugged that in a Wireshark session.
> Should I file a bug report?
> 
> I already sent a mail to TortoiseSVN ml [1] but was redirected here because 
> it uses Subversion libs to perform authentication.
> 
> A very interesting point is that I am running the same setup on FreeBSD and 
> the service ticket is successfully obtained for the proxy server.
> 
> Mike
> 
> [1] 
> http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2825191
> 

I'm sorry but I'm afraid I'll have to redirect you again.
Client-side NTLM authentication is done by neon, not Subversion.
Website: http://webdav.org/neon/

Proxy authentication with Negotiate uses wrong host

[1983-01-06]

Hi folks,

I am trying to make Subversion run with our ISA proxy which advertises 
Proxy-Authenticate: Negotiate, NTLM, Basic.

My Subversion version is: 1.6.7 on Windows XP, tried with 1.7-beta3 which even 
did not want to accept the URL. The HTTP lib is neon because serf quit working 
with "svn: Error running context: Internal error".
This is the UA sent by Subversion: SVN/1.6.17 (r1128011) neon/0.29.6

Now, when the proxy server challenges Subversion to authenticate, Subversion 
tries to retrieve a service ticket for the target host /instead of/ for the 
proxy host. I debugged that in a Wireshark session.
Should I file a bug report?

I already sent a mail to TortoiseSVN ml [1] but was redirected here because it 
uses Subversion libs to perform authentication.

A very interesting point is that I am running the same setup on FreeBSD and the 
service ticket is successfully obtained for the proxy server.

Mike

[1] 
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2825191
-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!   
Jetzt informieren: http://www.gmx.net/de/go/freephone

Re: Proxy authentication with Negotiate uses wrong host

[Stefan Sperling]

On Mon, Aug 22, 2011 at 01:02:26PM +0200, Stefan Sperling wrote:
> I'm sorry but I'm afraid I'll have to redirect you again.
> Client-side NTLM authentication is done by neon, not Subversion.
> Website: http://webdav.org/neon/

To clarify, neon also performs Negotiate auth.

Re: Proxy authentication with Negotiate uses wrong host

[Stefan Sperling]

On Mon, Aug 22, 2011 at 12:55:58PM +0200, 1983-01...@gmx.net wrote:
> Now, when the proxy server challenges Subversion to authenticate, Subversion 
> tries to retrieve a service ticket for the target host /instead of/ for the 
> proxy host. I debugged that in a Wireshark session.
> Should I file a bug report?

I've taken a look at neon, and it provides everything that's needed.
But the application must call ne_set_proxy_auth() for it to work.

Subversion only calls this if the http-proxy-username option has been
configured in the file ~/.subversion/servers.  Have you done that?

Re: Single-commit import with properties and SVN 1.7

[Ulrich Eckhardt]

On Monday 22 August 2011, Markus Schaber wrote:
> We need to add a new directory including files and properties to a
> subversion repository "in-place".

Just to be sure: There are auto-props, which could help in combination with an 
import. There is also svn_load_dirs, in case you need this for maintaining 
vendor branches.

> With SVN 1.6, the following did work: (I know that this is only an
> artifact and was no documented / intended behavior.)
> - Checkout the parent directory to a temporary place.
> - create and svn add the data directory under the parent working copy.
> - svn add and svn propset all the children we need in the working copy.
> - svn commit the parent directory (to add everything in a single
> commit.)
> - move the data directory to the intended working copy place.
> - delete the temporary parent directory.

Yes, there was some recent discussion whether to allow forking a child working 
copy from a parent working copy. If I remember correctly, this is out of 
question for 1.7 and rather something for 1.8 or 1.9.


> Is it theoretically possible with the new working copy architecture to
> allow the working copy root itself to be "scheduled for addition"?
> 
> This could be the base for a nice feature for SVN 1.8, allowing both
> "in-place import" and "import with properties", maybe some command like
> "svn checkout --for-addition
> svn://destination/url/to/some/non/existing/directory/with/existing/parent".

+1

I never use import, because I always get the exact repository location wrong, 
either one too few or one too many directory levels. Having something import-
like that creates a working copy would be a very interesting feature. It 
allows you to verify the target URL, set properties, exclude artifacts from 
builds or other version control systems, test stuff etc and do all that before 
committing.

I'm not sure it is feasible with the current or new WC design though, because 
additions are typically operations on the parent directory. I'm confident the 
SVN team will figure out a solution though.

Greetings!

Uli
**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
Visit our website at http://www.dominolaser.com
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

Re: Proxy authentication with Negotiate uses wrong host

[1983-01-06]

> Betreff: Re: Proxy authentication with Negotiate uses wrong host

> On Mon, Aug 22, 2011 at 12:55:58PM +0200, 1983-01...@gmx.net wrote:
> > Now, when the proxy server challenges Subversion to authenticate,
> Subversion tries to retrieve a service ticket for the target host /instead of/
> for the proxy host. I debugged that in a Wireshark session.
> > Should I file a bug report?
> 
> I've taken a look at neon, and it provides everything that's needed.
> But the application must call ne_set_proxy_auth() for it to work.
> 
> Subversion only calls this if the http-proxy-username option has been
> configured in the file ~/.subversion/servers.  Have you done that?

Stefan,

no, I did not set that value neither on Windows nor on FreeBSD. Using Negotiate 
does require setting a username. That's what the credentials cache is for.
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de


-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!   
Jetzt informieren: http://www.gmx.net/de/go/freephone

Re: Merge symmetry (was: Tree Conflicts with Subversion 1.7)

[Andreas Krey]

On Mon, 22 Aug 2011 12:38:40 +, Stefan Sperling wrote:
> On Fri, Aug 19, 2011 at 04:15:38PM +0200, Andreas Krey wrote:
...
> > Actually, merging is a symmetric operation. The tree (and copyfrom
> > info) resulting from a merge should be the same independent of in
> > which direction the merge is performed.
> 
> I agree that symmetry is a nice-to-have property of a merge algorithm.

I actually think it is essential.

> But I would be totally happy with asymmetric results, as long as either
> result is well-defined and repeatable.  I don't see why the behaviour
> of a merge algorithm must be symmetric.

Because a merge computes the addition of two changesets/diffs/however you
name that: The delta from branch point (or last merge point) to trunk,
and to branch head. I see no reason why the outcome should depend on
which side I choose as the base of the merge: addition is commutative.

Although the 'addition' part may be seen as wordplay, I'd like to see
a case where a merge could reasonably not be symmetric (barring cases
with conflicts, where the conflict presentation usually is unsymmetric).

> > In svn the metadata just looks
> > completely different depending on the direction of the merge. (It also
> > is different due to the necessity of --reintegrate.)
> 
> Sounds like you are conflating the UI with the underlying design.

No, I meant that besides the symmetry issue svn the mergeinfo actually
encode different information depending on the direction of the merge.

> --reintegrate is a UI issue and has nothing to do with symmetry
> or correctness.

I still don't quite understand why exactly --reintegrate is necessary.

Is it just because 'svn merge ^/branch' once meant 'take all changes of
branch since the branch point and merge them into trunk', and it shall
still mean that so we need --reintegrate to look closer onto the merge
info to use the source of the last sync merge instead of the branch
point as merge base? (But then we would need a 'merge --sync' as well.)

If it's not that, I don't see how the necessity of --reintegrate is an
UI issue and not a result of a suboptimal mergeinfo design, along with
the deadness of a branch after reintegration.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Tree Conflicts with Subversion 1.7

[Andreas Krey]

On Mon, 22 Aug 2011 12:49:25 +, Stefan Sperling wrote:
...
> > I'm used to manual merges, which means its always (p) with me. Which
> > unfortunately does not work quite well with properties, as far I
> > remember.
> 
> Can you provide details? What doesn't work, exactly?
> Is there already an issue filed for this problem?

It's not bug-worthy. AFAIR, when I (p) a property conflict, I get
the conflict markers into the property, and at least 'svn diff' does
not believe that properties (esp. svn:externals) may be multi-line,
and AFAIR you also just get both versions as a full-file conflict
in the property value. Doesn't make exactly easy to see what happened.
(I may also mingle this up with a property conflict after a regular 'svn up'.)

But as I unterstand, at least the multi-line property diffing is going to
get better.

...
> > One thing that would be helpful is (!): Run a shell.
> 
> I agree that would be nice.
> 
> However, right now, svn opens the prompt while the TCP connection
> to the server is still open.

And you think I can't open a new shell or ^Z the merge? It would be
seriously annoying if the merge then died on a timeout (which it may
just as well on the (e), which incidentally indirectly allows me to
spawn a shell).

...
> It's not going to be mandatory. It will be an optional helper,
> just like the current interactive conflict resolution prompt.

Good. Even the presentation of what exactly will be committed will
be interesting.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Proxy authentication with Negotiate uses wrong host

[Stefan Sperling]

On Mon, Aug 22, 2011 at 01:41:59PM +0200, 1983-01...@gmx.net wrote:
> no, I did not set that value neither on Windows nor on FreeBSD. Using 
> Negotiate does require setting a username. That's what the credentials cache 
> is for.

You expect svn to get the proxy username from the ~/.subversion/auth
cache?  That expection is not unreasonable, but it is not what the
implementation does, as far as I undestand (see
subversion/libsvn_ra_neon/session.c).

Have you tried setting the option to see if it fixes your problem?

I'm trying to figure out whether we should file an issue for this,
but I cannot do any testing myself. Your help is appreciated.

Re: Merge symmetry (was: Tree Conflicts with Subversion 1.7)

[Stefan Sperling]

On Mon, Aug 22, 2011 at 01:49:45PM +0200, Andreas Krey wrote:
> On Mon, 22 Aug 2011 12:38:40 +, Stefan Sperling wrote:
> > On Fri, Aug 19, 2011 at 04:15:38PM +0200, Andreas Krey wrote:
> ...
> > > Actually, merging is a symmetric operation. The tree (and copyfrom
> > > info) resulting from a merge should be the same independent of in
> > > which direction the merge is performed.
> > 
> > I agree that symmetry is a nice-to-have property of a merge algorithm.
> 
> I actually think it is essential.
> 
> > But I would be totally happy with asymmetric results, as long as either
> > result is well-defined and repeatable.  I don't see why the behaviour
> > of a merge algorithm must be symmetric.
> 
> Because a merge computes the addition of two changesets/diffs/however you
> name that: The delta from branch point (or last merge point) to trunk,
> and to branch head. I see no reason why the outcome should depend on
> which side I choose as the base of the merge: addition is commutative.

Because that's not how Subversion works.

In Subversion, a merge is the computation of a delta between two
arbitary trees, and the application of this delta to some other
arbitrary tree.

The merge target is *completely independent* of the merge delta.
There is nothing, in the core algorithm, that would know about stuff
like merge points and the like. You seem to be basing your mental
model of merge on tools like git or hg. And that is a very good model.
But it is very different from what Subversion is doing.

There is no merge DAG in Subversion.
The closest equivalent to a merge DAG is svn:mergeinfo, but it
doesn't implement a DAG -- it implements a filter that prevents
the same revisions from being merged twice. That's all.
It is really quite simple at the design level. The implementation
is not simple because it handles a lot of additional quirks that
are not reflected in this short and abstract description of what
Subversion is doing.
 
> > Sounds like you are conflating the UI with the underlying design.
> 
> No, I meant that besides the symmetry issue svn the mergeinfo actually
> encode different information depending on the direction of the merge.

Yes, that's true.

> > --reintegrate is a UI issue and has nothing to do with symmetry
> > or correctness.
> 
> I still don't quite understand why exactly --reintegrate is necessary.
> 
> Is it just because 'svn merge ^/branch' once meant 'take all changes of
> branch since the branch point and merge them into trunk', and it shall
> still mean that so we need --reintegrate to look closer onto the merge
> info to use the source of the last sync merge instead of the branch
> point as merge base? (But then we would need a 'merge --sync' as well.)
> 
> If it's not that, I don't see how the necessity of --reintegrate is an
> UI issue and not a result of a suboptimal mergeinfo design, along with
> the deadness of a branch after reintegration.

Let me quote the relevant part of the post I linked to:

[[[
Essentially, all merges in Subversion are 2-URL merges.
svn merge generates some delta and applies that to a working copy.
There is no other way, right now, that a merge could work.

A two-URL merge needs the following parameters:

  PATH1, REV1 (left side of the delta)
  PATH2, REV2 (right side of the delta)
  TARGET (working copy of some PATH3, up-to-date enough for commit)

The reintegrate merge automatically fills in all required parameters 
expect PATH2, and we get:

  PATH1 = trunk, REV1 = rX
  PATH2 = feature, REV2 = HEAD
  TARGET = working copy of trunk (generally speaking @HEAD)

A sync merge can fill in the all parameters as well, except PATH2.
However, it needs to do so in a different way. With a sync merge
PATH1 and PATH2 are the same so the delta between trunk@REV1 and
trunk@REV2 is merged into a working copy of the feature branch
In case of reintegrate PATH1 and PATH2 are not the same!

So svn merge needs the special --reintegrate option because just
'svn merge ^/branch' would be ambiguous.
]]]

Is that clear enough? If not, please ask.

Re: Tree Conflicts with Subversion 1.7

[Stefan Sperling]

On Mon, Aug 22, 2011 at 01:59:45PM +0200, Andreas Krey wrote:
> It's not bug-worthy. AFAIR, when I (p) a property conflict, I get
> the conflict markers into the property, and at least 'svn diff' does
> not believe that properties (esp. svn:externals) may be multi-line,
> and AFAIR you also just get both versions as a full-file conflict
> in the property value. Doesn't make exactly easy to see what happened.
> (I may also mingle this up with a property conflict after a regular 'svn up'.)
>
> But as I unterstand, at least the multi-line property diffing is going to
> get better.

Yes, this problem has been fixed in 1.7.
http://subversion.apache.org/docs/release-notes/1.7.html#diff-properties

> And you think I can't open a new shell or ^Z the merge?

Of course you can. You can also walk away from the screen and let
it sit there until the connection times out :)

> It would be
> seriously annoying if the merge then died on a timeout (which it may
> just as well on the (e), which incidentally indirectly allows me to
> spawn a shell).

Well, that's what happens right now. I agree that it isn't ideal.

Re: Bug in Subversion regarding file attributes

[Les Mikesell]

On 8/21/11 11:07 PM, Andy Canfield wrote:


WOW! So the .svn hidden directory contains a spare copy of every file in that
directory??? Why not just store a computed checksum?


The theory is that disk space is cheaper than a fast network.  And sometimes it 
is true...   It also lets the client do some operations (status/diff) offline 
and reduces the load on the server.



This means that putting a directory tree under version control doubles the size
of your working copy!


As you might note from the time it takes to create it.


[3] If a file has changed it will be uploaded in the commit.


I believe it sends some sort of diff containing the changes.


[4] File system attributes are only uploaded for a "svn new"; at all other times
file system attributes remain as they were when the file was first added to the
repository. So make darned sure you get the file system attributes correct when
you first add the file.


System attributes aren't maintained at all.


[5] To correct invalid file system attributes one must copy the file elsewhere,
svn delete, commit, recover from the copy, svn add, and svn commit again. This
works. It is not obvious that this will work, because although the file
disappears from your working copy it is still in the repository. So svn add
uploads the file attributes and svn commit *could* upload the file attributes
but it doesn't.


Just don't count on reproducing system attributes.  If they matter, make a 
script to set them correctly.



[6] The only file system attribute Subversion supports is the executable bit.
Otherwise all system attributes are kept as of when the file was originall 
NEW-ed.

Does this mean that if a file is NEW-ed under Windows then when it is checked
out under Linux it will be writable by everyone, which is the default in 
Windows?


I think this is controlled by the system defaults (process owner and umask on 
linux), not the source material.


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

Re: Proxy authentication with Negotiate uses wrong host

[1983-01-06]

> Betreff: Re: Proxy authentication with Negotiate uses wrong host

> On Mon, Aug 22, 2011 at 01:41:59PM +0200, 1983-01...@gmx.net wrote:
> > no, I did not set that value neither on Windows nor on FreeBSD. Using
> Negotiate does require setting a username. That's what the credentials cache
> is for.
> 
> You expect svn to get the proxy username from the ~/.subversion/auth
> cache?  That expection is not unreasonable, but it is not what the
> implementation does, as far as I undestand (see
> subversion/libsvn_ra_neon/session.c).

No, I don't expect svn to do that and imho there is no need to. I have 
double-checked on FreeBSD and there is no cache for the proxy because this is 
done by the GSSAPI externally.
 
> Have you tried setting the option to see if it fixes your problem?

Yes, I did with 'http-proxy-username = mumu'. No avail.
 
> I'm trying to figure out whether we should file an issue for this,
> but I cannot do any testing myself. Your help is appreciated.

I will help as much as I can.

Mike
-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!   
Jetzt informieren: http://www.gmx.net/de/go/freephone

AW: Single-commit import with properties and SVN 1.7

[Markus Schaber]

Hi, Uli,

Von: Ulrich Eckhardt [mailto:ulrich.eckha...@dominolaser.com]
> On Monday 22 August 2011, Markus Schaber wrote:
> > We need to add a new directory including files and properties to a
> > subversion repository "in-place".
> 
> Just to be sure: There are auto-props, which could help in combination
> with an import. There is also svn_load_dirs, in case you need this for
> maintaining vendor branches.

Auto-props won't help us, as we save object specific metadata
(Decoration for the repo browser, device configurations etc.) in the
properties.

Svn_load_dirs won't help us either, as our "source" is the CoDeSys
internal project database, and not a directory tree.

> > With SVN 1.6, the following did work: (I know that this is only an
> > artifact and was no documented / intended behavior.)
> > - Checkout the parent directory to a temporary place.
> > - create and svn add the data directory under the parent working
copy.
> > - svn add and svn propset all the children we need in the working
copy.
> > - svn commit the parent directory (to add everything in a single
> > commit.)
> > - move the data directory to the intended working copy place.
> > - delete the temporary parent directory.
> 
> Yes, there was some recent discussion whether to allow forking a child
> working copy from a parent working copy. If I remember correctly, this
is
> out of question for 1.7 and rather something for 1.8 or 1.9.

Forking the child tree would allow us to get rid of the second commit,
for the price of copying the data directory, instead of moving it. But
we could do the fork before populating all the subdirectories, so that
would be fast enough.

> > Is it theoretically possible with the new working copy architecture
to
> > allow the working copy root itself to be "scheduled for addition"?
> >
> > This could be the base for a nice feature for SVN 1.8, allowing both
> > "in-place import" and "import with properties", maybe some command
> > like "svn checkout --for-addition
> >
svn://destination/url/to/some/non/existing/directory/with/existing/paren
t".
> 
> +1
> 
> I never use import, because I always get the exact repository location
> wrong, either one too few or one too many directory levels. Having
> something import- like that creates a working copy would be a very
> interesting feature. It allows you to verify the target URL, set
> properties, exclude artifacts from builds or other version control
> systems, test stuff etc and do all that before committing.
> 
> I'm not sure it is feasible with the current or new WC design though,
> because additions are typically operations on the parent directory.
I'm
> confident the SVN team will figure out a solution though.

I consider this impossible with SVN 1.6 working copy format, as we need
the parent directory to exist for its metadata. But in SVN 1.7, we have
a central metadata storage in the workingcopy root, so I think it should
be doable.

Best regards

Markus Schaber

___
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 |
Fax +49-831-54031-50

Email: m.scha...@3s-software.com | Web: http://www.3s-software.com 
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects:
http://www.3s-software.com/index.shtml?sample_projects

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915

Re: Single-commit import with properties and SVN 1.7

[Mark Phippard]

On Mon, Aug 22, 2011 at 6:00 AM, Markus Schaber
wrote:

> Hi,
>
> We need to add a new directory including files and properties to a
> subversion repository "in-place".
>
> With SVN 1.6, the following did work: (I know that this is only an
> artifact and was no documented / intended behavior.)
> - Checkout the parent directory to a temporary place.
> - create and svn add the data directory under the parent working copy.
> - svn add and svn propset all the children we need in the working copy.
> - svn commit the parent directory (to add everything in a single
> commit.)
> - move the data directory to the intended working copy place.
> - delete the temporary parent directory.
>
> With SVN 1.7, I only see a way to do this with 2 commits:
> - svn remote add the data directory. (First commit)
> - checkout the data directory
> - fill the data directory with contents (files and properties)
> - svn commit the data directory. (Second commit).
> (This is analogeous to the "in-place import" in the FAQ.)
>
> Is it theoretically possible with the new working copy architecture to
> allow the working copy root itself to be "scheduled for addition"?
>
>
I am confused about why the exact same sequence of commands does not work
for you with 1.7.  What does the location of the .svn folder have to do with
any of this?

The problem to me, does not seem to be the import, which you can do with one
commit just fine.  It seems to be that after it it done, you want to move
this folder somewhere else to use it?  That can be done using the detach
script to copy it to the new location:

http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/detach.py



-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

AW: Single-commit import with properties and SVN 1.7

[Markus Schaber]

Hi, Mark,

Von: Mark Phippard [mailto:markp...@gmail.com] 

> On Mon, Aug 22, 2011 at 6:00 AM, Markus Schaber  
> wrote:

>> We need to add a new directory including files and properties to a
>> subversion repository "in-place".
>> 
>> With SVN 1.6, the following did work: (I know that this is only an
>> artifact and was no documented / intended behavior.)
>> - Checkout the parent directory to a temporary place.
>> - create and svn add the data directory under the parent working copy.
>> - svn add and svn propset all the children we need in the working copy.
>> - svn commit the parent directory (to add everything in a single
>>   commit.)
>> - move the data directory to the intended working copy place.
>> - delete the temporary parent directory.
>>
>> With SVN 1.7, I only see a way to do this with 2 commits:
>> - svn remote add the data directory. (First commit)
>> - checkout the data directory
>> - fill the data directory with contents (files and properties)
>> - svn commit the data directory. (Second commit).
>> (This is analogeous to the "in-place import" in the FAQ.)
>>
>> Is it theoretically possible with the new working copy architecture to
>> allow the working copy root itself to be "scheduled for addition"?

> I am confused about why the exact same sequence of commands does not work for 
> you with 1.7.  What does the location of the .svn folder have to do with any 
> of this?

The "Detaching" by moving the subdirectory to the desired place and then 
throwing the parent directory will not work with SVN 1.7.

> The problem to me, does not seem to be the import, which you can do with one 
> commit just fine.  It seems to be that after it is done, you want to move 
> this folder somewhere else to use it?  That can be done using the detach 
> script to copy it to the new location:
> http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/detach.py 

We do not insist in the "detach" step. The "detach" step just was part of the 
workaround to get an inplace-import with SVN 1.6, just as the second commit is 
part our workaround for SVN 1.7.

We need an inplace-import as we did make the decision to store object metadata 
in SVN properties. (Maybe that design decision was wrong. Currently, we still 
could change that design, as we did not release yet. All this is part of our 
mapping of the CoDeSys project database to a file-and-directory tree as needed 
by subversion.) Another reason for the in-place import is that it makes no 
sense to transfer the data over the network twice.

And the "moving" of the workingcopy was simplified use case - in fact, the 
working copy is zipped and packed into the project database file when the 
project is closed, so that the .project file can be transferred as normal and 
carries the working copy with it in a piggyback style. When the project is 
opened again, the working copy is unzipped into a new temporary directory.

Detaching via a python script is nice, but it has the disadvantage that we 
would need to deliver cPython as part of our software. (We currently deliver 
IronPython, but this has no supported subversion bindings yet.) 


Best regards

Markus Schaber

___
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax 
+49-831-54031-50

Email: m.scha...@3s-software.com | Web: http://www.3s-software.com 
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: 
http://www.3s-software.com/index.shtml?sample_projects

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade 
register: Kempten HRB 6186 | Tax ID No.: DE 167014915

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Single-commit import with properties and SVN 1.7

[Mark Phippard]

On Mon, Aug 22, 2011 at 11:31 AM, Markus Schaber
wrote:

>
> We do not insist in the "detach" step. The "detach" step just was part of
> the workaround to get an inplace-import with SVN 1.6, just as the second
> commit is part our workaround for SVN 1.7.
>
> We need an inplace-import as we did make the decision to store object
> metadata in SVN properties. (Maybe that design decision was wrong.
> Currently, we still could change that design, as we did not release yet. All
> this is part of our mapping of the CoDeSys project database to a
> file-and-directory tree as needed by subversion.) Another reason for the
> in-place import is that it makes no sense to transfer the data over the
> network twice.
>


I am confused about what does not work with an in-place import in 1.7.

$ svnadmin create repos
$ svn co file:///`pwd`/repos wc
Checked out revision 0.
$ mkdir wc/folder
$ echo foo > wc/folder/file.txt
$ svn add wc/folder
A wc/folder
A wc/folder/file.txt
$ svn ps customprop customvalue wc/folder
property 'customprop' set on 'wc/folder'
$ svn ps customprop customvalue wc/folder/file.txt
property 'customprop' set on 'wc/folder/file.txt'
$ svn ci -m "Commit changes" wc
Adding wc/folder
Adding wc/folder/file.txt
Transmitting file data .
Committed revision 1.
$ svn pl file:///`pwd`/repos/folder
Properties on 'file:///Users/markphip/tests/repos/folder':
  customprop
$ svn pl file:///`pwd`/repos/folder/file.txt
Properties on 'file:///Users/markphip/tests/repos/folder/file.txt':
  svn:mime-type
  customprop
  svn:eol-style

What does not work that worked with 1.6?

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

AW: Single-commit import with properties and SVN 1.7

[Markus Schaber]

Hi, Mark,

Von: Mark Phippard [mailto:markp...@gmail.com] 

> On Mon, Aug 22, 2011 at 11:31 AM, Markus Schaber
 wrote:

>> We do not insist in the "detach" step. The "detach" step just was
part of the workaround to get an inplace-import with SVN 1.6, just as
the second commit is part our workaround for SVN 1.7.

>>We need an inplace-import as we did make the decision to store object
metadata in SVN properties. (Maybe that design decision was wrong.
Currently, we still could change that design, as we did not release yet.
All this is part of our mapping of the CoDeSys project database to a
file-and-directory tree as needed by subversion.) Another reason for the
in-place import is that it makes no sense to transfer the data over the
network twice.


> I am confused about what does not work with an in-place import in 1.7.

> [Steps for in-place import]

> What does not work that worked with 1.6?

Those steps work nice, but they leave us with a working copy having the
parent of the project directory as its root, instead of the project
directory itself. This is why our Code for 1.6 had the "detach" step
which you left out in your commands, and which won't work with 1.7
anymore.


Best regards

Markus Schaber

___
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 |
Fax +49-831-54031-50

Email: m.scha...@3s-software.com | Web: http://www.3s-software.com 
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects:
http://www.3s-software.com/index.shtml?sample_projects

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 

Re: AW: Single-commit import with properties and SVN 1.7

[Andreas Krey]

On Mon, 22 Aug 2011 18:01:34 +, Markus Schaber wrote:

> > What does not work that worked with 1.6?
> 
> Those steps work nice, but they leave us with a working copy having the
> parent of the project directory as its root, instead of the project
> directory itself.

Is there a reason that you can't do your import directly in the project
directory, and is it prohibitive to just 'svn up' and throw away the
temp dir instead of moving the tree into the project dir?

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Single-commit import with properties and SVN 1.7

[Mark Phippard]

On Mon, Aug 22, 2011 at 12:01 PM, Markus Schaber
wrote:

> Those steps work nice, but they leave us with a working copy having the
> parent of the project directory as its root, instead of the project
> directory itself. This is why our Code for 1.6 had the "detach" step
> which you left out in your commands, and which won't work with 1.7
> anymore.
>


You said detach was optional before, but that is OK.  The conversation has
basically come back to the point I made in the original email.

Nothing has changed about in-place import.  That just happens to be the
tecnhique you used for your working copy.  Your real issue is that you can
no longer simply detach a working copy in 1.7.  That has been discussed on
this list before.  You are correct, you can't.  For now, there is a Python
script that can be used to do this.  Perhaps in a future release there will
be a formal subcommand.

Finally, keep in mind that I could have begun my recipe like this:

$ svn co --depth-empty url://server/repos/parent
$ mkdir child
$ svn add child
etc...

This would still mean the parent folder is the root of the WC, but it is at
least an empty parent folder if you are trying to avoid having other content
in the WC.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

AW: AW: Single-commit import with properties and SVN 1.7

[Markus Schaber]

Hi, Andreas,

Von: Andreas Krey [mailto:a.k...@gmx.de]
> On Mon, 22 Aug 2011 18:01:34 +, Markus Schaber wrote:
> 
> > > What does not work that worked with 1.6?
> >
> > Those steps work nice, but they leave us with a working copy having
> > the parent of the project directory as its root, instead of the
> > project directory itself.
> 
> Is there a reason that you can't do your import directly in the
project
> directory, and is it prohibitive to just 'svn up' and throw away the
temp
> dir instead of moving the tree into the project dir?

I cannot create a working copy directly in the project directory when
the project directory is just to be created with the import. This is why
we currently need an extra commit to create the project directory, as I
described it in my sequence of steps for SVN 1.7.

What exactly do you mean with "svn up" in this context?


Best regards

Markus Schaber

___
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 |
Fax +49-831-54031-50

Email: m.scha...@3s-software.com | Web: http://www.3s-software.com 
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects:
http://www.3s-software.com/index.shtml?sample_projects

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915

Re: Problems compiling 1.7.0 on redhat el4 64bit

[Philip Martin]

 writes:

> It is set to 1
>> 
>> Looking at the rest of the stack trace I would say this is the first
>> call to a utf8 conversion function that would have invoked
>> get_xlate_handle_node and I suspect it is that function that is going
>> wrong.  At a guess something to do with the use of atomic_swap, which
>> makes it important to confirm the value of APR_HAS_THREADS.

I wonder if it is connected to this APR bug:

https://issues.apache.org/bugzilla/show_bug.cgi?id=50731

In subversion/libsvn_subr/utf.c we declare

static volatile void *xlat_ntou_static_handle = NULL;
static volatile void *xlat_uton_static_handle = NULL;

that is "pointers to volatile data", as required by APR, but we really
want "volatile pointers to data".  Perhaps we should do something
similar to svn_cache_config.c.  Would you try this patch built with
optimisations enabled:

Index: subversion/libsvn_subr/utf.c
===
--- subversion/libsvn_subr/utf.c(revision 1160136)
+++ subversion/libsvn_subr/utf.c(working copy)
@@ -90,8 +90,8 @@
  * using atomic xchange ops, i.e. without further thread synchronization.
  * If the respective item is NULL, fallback to hash lookup.
  */
-static volatile void *xlat_ntou_static_handle = NULL;
-static volatile void *xlat_uton_static_handle = NULL;
+static void * volatile xlat_ntou_static_handle = NULL;
+static void * volatile xlat_uton_static_handle = NULL;
 
 /* Clean up the xlate handle cache. */
 static apr_status_t
@@ -182,11 +182,11 @@
  * the caller.
  */
 static APR_INLINE void*
-atomic_swap(volatile void **mem, void *new_value)
+atomic_swap(void * volatile * mem, void *new_value)
 {
 #if APR_HAS_THREADS
 #if APR_VERSION_AT_LEAST(1,3,0)
-   return apr_atomic_xchgptr(mem, new_value);
+   return apr_atomic_xchgptr((volatile void **)mem, new_value);
 #else
/* old APRs don't support atomic swaps. Simply return the
 * input to the caller for further proccessing. */


-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com

AW: Single-commit import with properties and SVN 1.7

[Markus Schaber]

Hi, Mark,

Von: Mark Phippard [mailto:markp...@gmail.com] 

> On Mon, Aug 22, 2011 at 12:01 PM, Markus Schaber  
> wrote:
>> Those steps work nice, but they leave us with a working copy having the
>> parent of the project directory as its root, instead of the project
>> directory itself. This is why our Code for 1.6 had the "detach" step
>> which you left out in your commands, and which won't work with 1.7
>> anymore.

> You said detach was optional before, but that is OK.  The conversation has 
> basically come back to the point I made in the original email.

With "optional", I wanted to express that we do not insist on detaching, if we 
find a different way for an in-place import leaving us with the correct parent 
directory (as in the proposal to have a working copy root itself scheduled for 
addition).

One of our goals is to keep the directory hierarchy as flat as possible, as the 
whole working copy itself lives in %APPDATA%\Local\Temp\ and the project 
hierarchies can be of arbitrary depth, with long names for the objects. (Some 
of our customers seem to do weird things, so the windows 255 character path 
limit is a serious concern for some of them...)

Best regards

Markus Schaber

___
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax 
+49-831-54031-50

Email: m.scha...@3s-software.com | Web: http://www.3s-software.com 
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: 
http://www.3s-software.com/index.shtml?sample_projects

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade 
register: Kempten HRB 6186 | Tax ID No.: DE 167014915

Re: Single-commit import with properties and SVN 1.7

[Mark Phippard]

On Mon, Aug 22, 2011 at 6:00 AM, Markus Schaber
wrote:


> We need to add a new directory including files and properties to a
> subversion repository "in-place".
>
> With SVN 1.6, the following did work: (I know that this is only an
> artifact and was no documented / intended behavior.)
> - Checkout the parent directory to a temporary place.
> - create and svn add the data directory under the parent working copy.
> - svn add and svn propset all the children we need in the working copy.
> - svn commit the parent directory (to add everything in a single
> commit.)
> - move the data directory to the intended working copy place.
> - delete the temporary parent directory.
>
> With SVN 1.7, I only see a way to do this with 2 commits:
> - svn remote add the data directory. (First commit)
> - checkout the data directory
> - fill the data directory with contents (files and properties)
> - svn commit the data directory. (Second commit).
> (This is analogeous to the "in-place import" in the FAQ.)
>

This also should work:

$ svn co --depth=empty url://server/repos/parent tmp
$ fill with data directory and files
$ svn add data
$ set properties
$ svn ci -m Commit the data folder

$ svn co url://server/repos/parent/data  real_dir


-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Merge symmetry (was: Tree Conflicts with Subversion 1.7)

[Andreas Krey]

On Mon, 22 Aug 2011 14:36:36 +, Stefan Sperling wrote:
...
> In Subversion, a merge is the computation of a delta between two
> arbitary trees, and the application of this delta to some other
> arbitrary tree.

To keep the (vector) addition analogy, you are measuring the difference
from A to B and move C in this direction. Which yields the same as
measuring from A to C and move B in *that* direction. You end up in the
same point. Just once B ends up there, and once C.

Anyway, while that is what you tell, and probably do for directories,
you can't get around using a version of the (symmetrical) diff3 to merge
file contents; that is the only way to sanely apply the delta. An actual
delta (patch) wouldn't generally be applicable to the target file.

> The merge target is *completely independent* of the merge delta.
> There is nothing, in the core algorithm, that would know about stuff
> like merge points and the like.

No, that comes into play when selecting the two revisions and paths that
you need to compute the delta to apply.

> You seem to be basing your mental
> model of merge on tools like git or hg. And that is a very good model.
> But it is very different from what Subversion is doing.

Unfortunately it is not that different from what I expected when
subversion was said to get proper merge support. (I was pampered
by cvsnt, which (once) could do bidirectional merges.)

> There is no merge DAG in Subversion.
> The closest equivalent to a merge DAG is svn:mergeinfo, but it
> doesn't implement a DAG -- it implements a filter that prevents
> the same revisions from being merged twice. That's all.

And unfortunately, it is so simplistic that you need to prod it with
--reintegrate the first (and last) time you merge in the other direction.
(Or it seems so.)

> It is really quite simple at the design level. The implementation
> is not simple because it handles a lot of additional quirks that
> are not reflected in this short and abstract description of what
> Subversion is doing.

Yes, recorded cherrypicking, not to mention all the rename handling.

...
> Let me quote the relevant part of the post I linked to:
...
> Is that clear enough? If not, please ask.

It's not quite. But it seems I need to wade through what actually happens
with the mergeinfo to understand why a backmerge can't deduce the proper
action without --reintegrate, and why the merge info then needs to be
borken for the branch. (Which may be partly simply because you can't
modify the branch's mergeinfo to mark the merge revision on the trunk
as already merged.)

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

RE: Problems compiling 1.7.0 on redhat el4 64bit

[michael_rytting]

No luck, still crashing.

-Original Message-
From: Philip Martin [mailto:philip.mar...@wandisco.com] 
Sent: Monday, August 22, 2011 10:23 AM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: markp...@gmail.com; d...@subversion.apache.org; users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit

 writes:

> It is set to 1
>> 
>> Looking at the rest of the stack trace I would say this is the first 
>> call to a utf8 conversion function that would have invoked 
>> get_xlate_handle_node and I suspect it is that function that is going 
>> wrong.  At a guess something to do with the use of atomic_swap, which 
>> makes it important to confirm the value of APR_HAS_THREADS.

I wonder if it is connected to this APR bug:

https://issues.apache.org/bugzilla/show_bug.cgi?id=50731

In subversion/libsvn_subr/utf.c we declare

static volatile void *xlat_ntou_static_handle = NULL; static volatile void 
*xlat_uton_static_handle = NULL;

that is "pointers to volatile data", as required by APR, but we really want 
"volatile pointers to data".  Perhaps we should do something similar to 
svn_cache_config.c.  Would you try this patch built with optimisations enabled:

Index: subversion/libsvn_subr/utf.c
===
--- subversion/libsvn_subr/utf.c(revision 1160136)
+++ subversion/libsvn_subr/utf.c(working copy)
@@ -90,8 +90,8 @@
  * using atomic xchange ops, i.e. without further thread synchronization.
  * If the respective item is NULL, fallback to hash lookup.
  */
-static volatile void *xlat_ntou_static_handle = NULL; -static volatile void 
*xlat_uton_static_handle = NULL;
+static void * volatile xlat_ntou_static_handle = NULL; static void * 
+volatile xlat_uton_static_handle = NULL;
 
 /* Clean up the xlate handle cache. */
 static apr_status_t
@@ -182,11 +182,11 @@
  * the caller.
  */
 static APR_INLINE void*
-atomic_swap(volatile void **mem, void *new_value)
+atomic_swap(void * volatile * mem, void *new_value)
 {
 #if APR_HAS_THREADS
 #if APR_VERSION_AT_LEAST(1,3,0)
-   return apr_atomic_xchgptr(mem, new_value);
+   return apr_atomic_xchgptr((volatile void **)mem, new_value);
 #else
/* old APRs don't support atomic swaps. Simply return the
 * input to the caller for further proccessing. */


--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com

Re: Problems compiling 1.7.0 on redhat el4 64bit

[Mark Phippard]

Michael, did you ever get a chance trying the -fno-strict-aliasing flag
rather than removing all optimizations?



On Mon, Aug 22, 2011 at 12:43 PM,  wrote:

> No luck, still crashing.
>
> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: Monday, August 22, 2011 10:23 AM
> To: RYTTING,MICHAEL (A-ColSprings,ex1)
> Cc: markp...@gmail.com; d...@subversion.apache.org;
> users@subversion.apache.org
> Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
>
>  writes:
>
> > It is set to 1
> >>
> >> Looking at the rest of the stack trace I would say this is the first
> >> call to a utf8 conversion function that would have invoked
> >> get_xlate_handle_node and I suspect it is that function that is going
> >> wrong.  At a guess something to do with the use of atomic_swap, which
> >> makes it important to confirm the value of APR_HAS_THREADS.
>
> I wonder if it is connected to this APR bug:
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50731
>
> In subversion/libsvn_subr/utf.c we declare
>
> static volatile void *xlat_ntou_static_handle = NULL; static volatile void
> *xlat_uton_static_handle = NULL;
>
> that is "pointers to volatile data", as required by APR, but we really want
> "volatile pointers to data".  Perhaps we should do something similar to
> svn_cache_config.c.  Would you try this patch built with optimisations
> enabled:
>
> Index: subversion/libsvn_subr/utf.c
> ===
> --- subversion/libsvn_subr/utf.c(revision 1160136)
> +++ subversion/libsvn_subr/utf.c(working copy)
> @@ -90,8 +90,8 @@
>  * using atomic xchange ops, i.e. without further thread synchronization.
>  * If the respective item is NULL, fallback to hash lookup.
>  */
> -static volatile void *xlat_ntou_static_handle = NULL; -static volatile
> void *xlat_uton_static_handle = NULL;
> +static void * volatile xlat_ntou_static_handle = NULL; static void *
> +volatile xlat_uton_static_handle = NULL;
>
>  /* Clean up the xlate handle cache. */
>  static apr_status_t
> @@ -182,11 +182,11 @@
>  * the caller.
>  */
>  static APR_INLINE void*
> -atomic_swap(volatile void **mem, void *new_value)
> +atomic_swap(void * volatile * mem, void *new_value)
>  {
>  #if APR_HAS_THREADS
>  #if APR_VERSION_AT_LEAST(1,3,0)
> -   return apr_atomic_xchgptr(mem, new_value);
> +   return apr_atomic_xchgptr((volatile void **)mem, new_value);
>  #else
>/* old APRs don't support atomic swaps. Simply return the
> * input to the caller for further proccessing. */
>
>
> --
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com
>



-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

RE: Problems compiling 1.7.0 on redhat el4 64bit

[michael_rytting]

I did.  It didn't help.

-Mike

From: Mark Phippard [mailto:markp...@gmail.com]
Sent: Monday, August 22, 2011 10:48 AM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: philip.mar...@wandisco.com; d...@subversion.apache.org; 
users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit

Michael, did you ever get a chance trying the -fno-strict-aliasing flag rather 
than removing all optimizations?



On Mon, Aug 22, 2011 at 12:43 PM, 
mailto:michael_rytt...@agilent.com>> wrote:
No luck, still crashing.

-Original Message-
From: Philip Martin 
[mailto:philip.mar...@wandisco.com]
Sent: Monday, August 22, 2011 10:23 AM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: markp...@gmail.com; 
d...@subversion.apache.org; 
users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
mailto:michael_rytt...@agilent.com>> writes:

> It is set to 1
>>
>> Looking at the rest of the stack trace I would say this is the first
>> call to a utf8 conversion function that would have invoked
>> get_xlate_handle_node and I suspect it is that function that is going
>> wrong.  At a guess something to do with the use of atomic_swap, which
>> makes it important to confirm the value of APR_HAS_THREADS.

I wonder if it is connected to this APR bug:

https://issues.apache.org/bugzilla/show_bug.cgi?id=50731

In subversion/libsvn_subr/utf.c we declare

static volatile void *xlat_ntou_static_handle = NULL; static volatile void 
*xlat_uton_static_handle = NULL;

that is "pointers to volatile data", as required by APR, but we really want 
"volatile pointers to data".  Perhaps we should do something similar to 
svn_cache_config.c.  Would you try this patch built with optimisations enabled:

Index: subversion/libsvn_subr/utf.c
===
--- subversion/libsvn_subr/utf.c(revision 1160136)
+++ subversion/libsvn_subr/utf.c(working copy)
@@ -90,8 +90,8 @@
 * using atomic xchange ops, i.e. without further thread synchronization.
 * If the respective item is NULL, fallback to hash lookup.
 */
-static volatile void *xlat_ntou_static_handle = NULL; -static volatile void 
*xlat_uton_static_handle = NULL;
+static void * volatile xlat_ntou_static_handle = NULL; static void *
+volatile xlat_uton_static_handle = NULL;

 /* Clean up the xlate handle cache. */
 static apr_status_t
@@ -182,11 +182,11 @@
 * the caller.
 */
 static APR_INLINE void*
-atomic_swap(volatile void **mem, void *new_value)
+atomic_swap(void * volatile * mem, void *new_value)
 {
 #if APR_HAS_THREADS
 #if APR_VERSION_AT_LEAST(1,3,0)
-   return apr_atomic_xchgptr(mem, new_value);
+   return apr_atomic_xchgptr((volatile void **)mem, new_value);
 #else
   /* old APRs don't support atomic swaps. Simply return the
* input to the caller for further proccessing. */


--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com



--
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: AW: Single-commit import with properties and SVN 1.7

[Andreas Krey]

On Mon, 22 Aug 2011 18:17:48 +, Markus Schaber wrote:
...
> I cannot create a working copy directly in the project directory when
> the project directory is just to be created with the import.

Oops, forget it. I misunderstood the requirement.

Anyway, is throwing away the import sandbox and checking out the project
dir too expensive?

Andreas

Please help - 403 Forbidden error

[Cathy Arakaki]

I am not sure what changed recently, but I have been working on a hook to
verify that a phrase is included in files before they are committed and now
I am getting this message when I try to do the commit.  I just created a
new repository without any hooks and I am getting the same message when I
try to import the initial tags, trunk and branches:


What am I doing wrong?

Cathy Arakaki
Subversion Control Manager
310-616-1148<>

Re: Please help - 403 Forbidden error

[Les Mikesell]

On 8/22/2011 12:54 PM, Cathy Arakaki wrote:

I am not sure what changed recently, but I have been working on a hook
to verify that a phrase is included in files before they are committed
and now I am getting this message when I try to do the commit. I just
created a new repository without any hooks and I am getting the same
message when I try to import the initial tags, trunk and branches:



A 403 error from the web server on a new repository means you don't have 
permission to write there, either due to configuration or file system 
permissions.


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

Re: BUG: Inconsistent handling of challenge-on-commit for conflicting user credentials

[Thomas Robinson]

Daniel:

As mentioned in my original mail, this is indeed a cache invalidation 
problem reliant on the contents of ~/.subversion/auth, which is 
trivially worked around by removing the contents thereof. The problem 
I'm trying to raise is a lack of parity with the behavior of plain SVN, 
which also handles the server challenge on commit poorly but in a less 
obtrusive way. That is, in their case, --username takes precedence over 
the contents of the cache.


In both cases, the lack of a descriptive error message is more 
problematic than the lack of an automated fix for the problem. I have of 
course raised the issue with SVN as well, such that if they add this 
message, Git will also handle this issue more gracefully when the 
changes are integrated through Perl SVN.



Thank you for your response,
- Tom Robinson

On 8/20/11 5:08 AM, Daniel Shahaf wrote:

Passing --username at checkout time is a no-op for HTTP-served
repositories that allow anonymous read access.

Seems that you have your username/password cached on the first box but
not on the second box?

In any case: rm -rf ~/.subversion/auth/svn.simple/ will remove the
locally-cached usernames/passwords.  (Note for the archives: it won't
remove details associated with client certificates.)  Or, alternatively,
pass --username to the 'svn commit' command too.

Does this address your issue?



Thomas Robinson wrote on Fri, Aug 19, 2011 at 14:06:40 -0700:

The following is a bug report for triage and review. I've been
unable to locate an adequate fix or discussion for this issue;
however, I have found an acceptable workaround.


When built on OSX, SVN versions 1.6.16 (r1073529) and 1.6.17
(r1128011) appear to handle authentication challenges on commit in a
non-robust manner.

The testing that follows is against a Google Code project that I
currently maintain code for, which may be found here:
http://code.google.com/p/rf-ace/


Here is a sparse log of a fresh checkout and commit using SVN
version 1.6.16 (r1073529) on OSX. All builds are inclusive of
ra-neon:

$ svn checkout https://rf-ace.googlecode.com/svn/trunk/ rf-ace.svn
--username trobin...@systemsbiology.org
... file data ...
Checked out revision 265.

$ cd rf-ace.svn
... make some changes to existing files ...

$ svn commit
... write the log in my default editor ...

"svn-commit.tmp" 35L, 1392C written
svn: Commit failed (details follow):
svn: access to '/svn/!svn/act/c23cbe26-fda3-46d6-a358-d1d20738c4bf'
forbidden
svn: Your commit message was left in a temporary file:
svn: '/path/to/my/repo/scrubbed/from/this/report/rf-ace.svn/svn-commit.tmp'

This same behavior exhibits in 1.6.17 (r1128011), and when a log
message is given using -m.



Here is an approximately equivalent session using SVN version 1.6.11
(r934486) in CentOS 6:

$ svn checkout https://rf-ace.googlecode.com/svn/trunk/ rf-ace
--username trobin...@systemsbiology.org
... file data ...
Checked out revision 265.

$ cd rf-ace
... make some changes to existing files ...

$ svn up
... file data ...
Checked out revision 269.

$ svn commit -m "Irrelevant log message you can find in r270 of rf-ace"
Authentication realm:  Google
Code Subversion Repository
Password for 'trobinso':
[In which I press enter here to fall back to explicit Username
specification]

Authentication realm:  Google
Code Subversion Repository
Username: trobin...@systemsbiology.org
Password for 'trobin...@systemsbiology.org': [My correct password is
entered here]
Sendingtest/argparse_test.hpp
Transmitting file data .
---
ATTENTION!  Your password for authentication realm:

  Google Code Subversion Repository

can only be stored to disk unencrypted!  You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible.  See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/my/home/directory/.subversion/servers'.
---
Store password unencrypted (yes/no)? yes [I know, I know. See my
notes below.]

Committed revision 270.


Note that on personal dev boxes, authentication information has been
stored locally in ~/.subversion (which, I note as an aside, is
something I only do with definedly-insecure passwords like those
automatically generated by Google Code on machines that are for
internal development only). This, too, may cause the issue.

My workaround, of course, is obvious. For all versions of SVN,
specifying the username explicitly (a la "--username
trobin...@systemsbiology.org") immediately follows up with a
challenge for my password. I have not verified if this resolves
future commit attempts.


The catalyst for the issue is Google's recent transition of Google
Code login

Re: Please help - 403 Forbidden error

[Daniel Shahaf]

Wouldn't filesystem permissions yield 500?

Les Mikesell wrote on Mon, Aug 22, 2011 at 13:42:07 -0500:
> On 8/22/2011 12:54 PM, Cathy Arakaki wrote:
> >I am not sure what changed recently, but I have been working on a hook
> >to verify that a phrase is included in files before they are committed
> >and now I am getting this message when I try to do the commit. I just
> >created a new repository without any hooks and I am getting the same
> >message when I try to import the initial tags, trunk and branches:
> >
> 
> A 403 error from the web server on a new repository means you don't
> have permission to write there, either due to configuration or file
> system permissions.
> 
> -- 
>   Les Mikesell
>lesmikes...@gmail.com
> 

Re: SVN in Z-LINUX

[Nico Kadel-Garcia]

On Mon, Aug 22, 2011 at 4:27 AM, shrinivasan  wrote:
> On Saturday 20 August 2011 07:35 AM, dvia...@proderj.rj.gov.br wrote:
>>
>> Hi,
>>
>> We use SVN in intel paltform, with Debian (Ubuntu).
>> We intend to use it in mainframe Z-LINUX / redhat (with Z-VM archteture ).
>> Can we go on, or it´s just kown that it will not work ?
>>
>>
>
> You can download the source from
> http://subversion.apache.org/download/
>
> and compile for z-linux.
>
> It will work as usual.

That isn't integrated with contemporary RPM package management for
Linux. The RPMforge SRPM's are, and I'd try working from those for the
moment, until I finish debugging and testing the 1.6.17 SRPM for
RPMforge (or somone else beats me to it, the new job is taking up some
valuable time).

AW: Single-commit import with properties and SVN 1.7

[Markus Schaber]

Hi, Mark,

Von: Mark Phippard [mailto:markp...@gmail.com] 
>> [ in place checkout]

> This also should work:
> 
> $ svn co --depth=empty url://server/repos/parent tmp
> $ fill with data directory and files
> $ svn add data
> $ set properties
> $ svn ci -m Commit the data folder
> 
> $ svn co url://server/repos/parent/data  real_dir

Yes, but it comes at the price of transferring the data twice over the network. 
And some working copies might be rather large.

So, for now, the two-commit solution seems to be the best workaround.

Best regards

Markus Schaber
-- 
___
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax 
+49-831-54031-50

Email: m.scha...@3s-software.com | Web: http://www.3s-software.com 
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: 
http://www.3s-software.com/index.shtml?sample_projects

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade 
register: Kempten HRB 6186 | Tax ID No.: DE 167014915

AW: AW: Single-commit import with properties and SVN 1.7

[Markus Schaber]

Hi, Andreas,

Von: Andreas Krey [mailto:a.k...@gmx.de]
> On Mon, 22 Aug 2011 18:17:48 +, Markus Schaber wrote:
> ...
> > I cannot create a working copy directly in the project directory when
> > the project directory is just to be created with the import.
> 
> Oops, forget it. I misunderstood the requirement.

We also have some users which commit into an existing empty directory - then 
the whole thing is no problem. But in some cases our users want to create the 
project directory with the checkin.

> Anyway, is throwing away the import sandbox and checking out the project
> dir too expensive?

As our working copies for existing projects may be several hundred MB with 
several thousand files, the time problem is considered worse than the 
two-commit approach we do now.


Mit freundlichen Grüßen

Markus Schaber

___
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Entwicklung
Memminger Str. 151 | 87439 Kempten | Tel. +49-831-54031-0 | Fax +49-831-54031-50

Email: m.scha...@3s-software.com | Web: http://www.3s-software.com 
CoDeSys Internet-Forum: http://forum.3s-software.com

Geschäftsführer: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | 
Handelsregister: Kempten HRB 6186 | USt-IDNr.: DE 167014915