Re: check-mime-type, Windows client, non-ASCII path

[Eliop]

Hello, Nico.

El 1 de febrero de 2012 13:17, Nico Kadel-Garcia escribió:

2012/2/1 Ignacio González (Eliop) :
> > Clients: Windows-XP, Windows 7, svn 1.6.16 (Spanish)
> > Server: Linux (CentOS), svn 1.6.16 (Spanish)
> >
> > Repository created OK
> > Hundreds of revisions already checked-in OK
> > Hook "check-mime-type" (bash) added in server
> > A couple of revisions checked-in OK
> > New file added with non-ASCII characters -> Problem:
> > Path name (in Windows, client): C:\Usuarios\arenero\Inútil.TXT
> > (note the u with an acute accent: ú)
> >
> > C:\Usuarios\arenero>svn ci acentos -m "Prueba 1"
> > Adding acentos
> > Adding acentos\In£til.TXT
> > Transmitting file data .svn: Commit failed (details follow):
> > svn: Commit blocked by pre-commit hook (exit code 1) with output:
> > /opt/csvn/data/repositories/telecontrol/hooks/check-mime-type:
> > `/opt/csvn/bin/sv
> > nlook proplist /opt/csvn/data/repositories/arenero -t 44-1e --verbose
> > acentos/In
> > ?\195?\186til.TXT' failed with this output:
> > svnlook: Path 'acentos/In?\195?\186til.TXT' does not exist
> >
> > To help diagnose it, I tried to check out an already existing file with
> > accents in its name
> > (checked in before the Hook "check-mime-type" (bash) was added in the
> > server).
> > Check out fails.
> > Oh, my God.
> >
> > Suggestions ?
>
> First, avoid non-ascii characters in file names.


Yes, I tend to do so, especially with software code.
But, al last, we  convinced our hardware, marketing and field people
to use Subversion as well. Please don't suggest me to tell them to stop
naming the documents they produce without accents and ñ :-)
I can hear them: 'What the heck? Until yesterday I was able to navigate
with my web browser your repository and all the documents had the names I
gave them. You are telling me now that you are re-naming them? Crazy!'


> It causes real
> problems with pre-commit hooks


Yes!


> and post-commit hooks that do not
> properly quote their arguments, and that's not something you can
> handle on the client side. And I've had network file shares used for
> working copies, such as NetApp serviced home directories NFS mounted
> as /home/$USER on the Linux side and CIFS mounted $HOMEDIR on the
> Windows side, where people generated files on the Windows side,
> successfully checked them in, and couldn't successfully read or delete
> the files on the Linux NFS side because the server hadn't been set up
> with UTF compatible NetApp filesystems.
>
> Second, can you check out the *directory* that ocntains the file by
> using the directory name, and letting the client deal with the
> wackiness?


Done it. No joy :-(


> And can you use 'svn mv', or do your operations with a
> TortoiseSVN client, which is really handy for getting files with funny
> names correctly processed?
>

95 % of our uses use TortoiseSVN to check-in and check-out. Many of them
use a browser to surf the repository. In fact, the problems I reported were
found using TortoiseSVN, so the first thing I always do in these cases
is to check the problem with svn command line. In this case,
the observed behaviour was the same.

I cannot imagine a sensible way of using svn mv with the files that are
already
checked-in with Windows clients and want to check out from Linux clients.

Is there some way to force the Linux server / svn server / svn hooks to use
the
'Windows'  filename convention, whatever it is?

Is there some way to reprocess (dump / load or whatever) the whole
repository in order to make happy both Linux clients and Windows clients
without changing the non-ASCII characters as seen by both clients?

What I was really surprised is to see that the filenames flowing through the
communication channel is not normalised (well, that is just speculation,
am I wrong?). Is there a way to force the clients to convert the names
to same canonical form (e.g., UTF-8) and back to the resident filesystem
convention again?

What are doing my Czech, German and Turk friends in this forum?

Re: Upgrade Subversion 1.4.3

[Les Mikesell]

On Wed, Feb 1, 2012 at 11:49 AM, David Chapman  wrote:
>
>>
>>> Actually the Working Copies are automatically upgraded when "touched" for
>>> the first time by the new version. The Repositories are NOT automatically
>>> upgraded, but it's a manual step through svnadmin upgrade (which mean
>>> *you*
>>> decide if and when to upgrade the repository).
>>
>> that the repositories could use the svnadmin upgrade.  Would I still have
>> to do a dump/reload if I did the upgrade?
>>
>
> Not required, but strongly encouraged.  If your repository is large (many
> gigabytes) and you have many users, the downtime for a dump/load cycle can
> be problematic.  But if you can afford to have the repository down for a
> little longer than the time required to switch the server from the old
> Subversion release to the new Subversion release, a dump/load can give you
> many benefits - not the least of which is repository sharding, to avoid
> having tens of thousands of revision files in a single directory.
>
> Now you know why many admins work late nights or weekends.  :-(

Alternatively you can make a new repository and use svnsync to copy
the old content over, then substitute the new for the old at a point
when it is caught up.   I'm not sure the exact steps are well
documented, but it has the advantage of working incrementally so you
can start well ahead of cutover and the final sync happens quickly and
without needing intermediate storage space for the dump copy.

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

Re: Upgrade Subversion 1.4.3

[Stefan Sperling]

On Wed, Feb 01, 2012 at 09:49:58AM -0800, David Chapman wrote:
> On 2/1/2012 9:26 AM, James Boden wrote:
> >Earlier it was stated by Andy
> >>Actually the Working Copies are automatically upgraded when "touched" for
> >>the first time by the new version. The Repositories are NOT automatically
> >>upgraded, but it's a manual step through svnadmin upgrade (which mean *you*
> >>decide if and when to upgrade the repository).
> >that the repositories could use the svnadmin upgrade.  Would I still have to 
> >do a dump/reload if I did the upgrade?
> >
> 
> Not required, but strongly encouraged.  If your repository is large
> (many gigabytes) and you have many users, the downtime for a
> dump/load cycle can be problematic.  But if you can afford to have
> the repository down for a little longer than the time required to
> switch the server from the old Subversion release to the new
> Subversion release, a dump/load can give you many benefits - not the
> least of which is repository sharding, to avoid having tens of
> thousands of revision files in a single directory.
> 
> Now you know why many admins work late nights or weekends.  :-(

I would recommend 'svnadmin upgrade' instead of dump/load, unless you
are already having specific problems addressed by new features which
require a dump/load to be effective for existing revision data.

So if, for example, the size or the number of files in your existing
repositories does not bother you, there is no point in wasting time
for a dump/load cycle. 'svnadmin upgrade' takes virtually no time at all.

You may even choose not to upgrade your repositories at all.
They will continue operating like they did with a 1.4 server.
But you will again be running a supported server version which receives
bug fixes in point releases, and newly created repositories will use
the new features automatically.
If users of existing repositories do not need the new features
offered by an upgrade then this is probably your best option.

Re: Upgrade Subversion 1.4.3

[David Chapman]

On 2/1/2012 9:26 AM, James Boden wrote:

Earlier it was stated by Andy

Actually the Working Copies are automatically upgraded when "touched" for
the first time by the new version. The Repositories are NOT automatically
upgraded, but it's a manual step through svnadmin upgrade (which mean *you*
decide if and when to upgrade the repository).

that the repositories could use the svnadmin upgrade.  Would I still have to do 
a dump/reload if I did the upgrade?



Not required, but strongly encouraged.  If your repository is large 
(many gigabytes) and you have many users, the downtime for a dump/load 
cycle can be problematic.  But if you can afford to have the repository 
down for a little longer than the time required to switch the server 
from the old Subversion release to the new Subversion release, a 
dump/load can give you many benefits - not the least of which is 
repository sharding, to avoid having tens of thousands of revision files 
in a single directory.


Now you know why many admins work late nights or weekends.  :-(

--
David Chapman dcchap...@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com

RE: Upgrade Subversion 1.4.3

[James Boden]

Earlier it was stated by Andy
> Actually the Working Copies are automatically upgraded when "touched" for
> the first time by the new version. The Repositories are NOT automatically
> upgraded, but it's a manual step through svnadmin upgrade (which mean *you*
> decide if and when to upgrade the repository).

that the repositories could use the svnadmin upgrade.  Would I still have to do 
a dump/reload if I did the upgrade?


James Boden
IT Specialist
Western Regional Center for Correctional Ed
18415 Roxbury Road
Hagerstown, Md. 21740
301-766-9443
jbo...@dllr.state.md.us


From: Stefan Sperling [s...@elego.de]
Sent: Wednesday, February 01, 2012 12:16 PM
To: James Boden
Cc: Andy Levy; Giulio Troccoli; users@subversion.apache.org
Subject: Re: Upgrade Subversion 1.4.3

On Wed, Feb 01, 2012 at 05:11:55PM +, James Boden wrote:
> Andy, what do you mean svadmin dump/load route?  Is this for the 
> repositories?  Sorry for being dense here, I just mainly use the software and 
> not do a lot of maintenance to it.

Yes, it's for repositories.
See 
http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate

Re: Upgrade Subversion 1.4.3

[Stefan Sperling]

On Wed, Feb 01, 2012 at 05:11:55PM +, James Boden wrote:
> Andy, what do you mean svadmin dump/load route?  Is this for the 
> repositories?  Sorry for being dense here, I just mainly use the software and 
> not do a lot of maintenance to it.

Yes, it's for repositories.
See 
http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate

Re: Upgrade Subversion 1.4.3

[Stefan Sperling]

On Wed, Feb 01, 2012 at 11:51:17AM -0500, Andy Levy wrote:
> There are a number of distributions available, both from
> companies/individuals (CollabNet, WANDisco, etc.) and OS
> distributions. What is available to you and how the installation
> process gets run will depend upon what OS your server is running and
> what distribution you select.

A good list is at http://subversion.apache.org/packages.html

Re: Problem with reverting

[Stefan Sperling]

On Wed, Feb 01, 2012 at 03:27:13PM +, Markus Schaber wrote:
> Hi,
> 
> I have a directory foo with tree conflict: local add of foo and a file 
> foo/bar, and then an update trying to add the same foo and foo/bar. Now, I 
> try to revert using SharpSVN, which internally calls svn_client_revert_2(). I 
> give the path of the directory and the file, and a depth of "files". Then I 
> get the Exception Can't revert 'C:\Users\{...}\foo' without reverting 
> children", SVN_ERR_WC_INVALID_OPERATION_DEPTH. 
> 
> I can reproduce that on the command line, getting the additional hint that I 
> should use --depth="infinity" instead. That seems to indicate that reverts of 
> added directories always need --depth="infinity", despite the fact that all 
> existing children are also mentioned in the argument list.
> 
> C:\{...}\svnwc>svn status
> R C Device\Plc Logic\Application\Library Manager
>   >   local add, incoming add upon update
> A   Device\Plc Logic\Application\Library Manager\svnobj
> Summary of conflicts:
>   Tree conflicts: 1
> 
> C:\{...}\svnwc>svn revert --depth=files "Device\Plc Logic\Application\Library 
> Manager" "Device\Plc  Logic\Application\Library Manager\svnobj"
> svn: E155038: Try 'svn revert --depth infinity' instead?
> svn: E155038: Can't revert 'C:\{...}\svnwc\Device\Plc 
> Logic\Application\Library Manager' without r everting children
> 
> 
> The strange thing is that if I change the order of arguments, it works 
> without errors, but misses to restore the "svnobj" file from the repository, 
> marking it as "deleted" - despite the fact that both --depth=files and the 
> file's path are given on the command line.
> 
> C:\{...}\svnwc>svn revert --depth=files "Device\Plc Logic\Application\Library 
> Manager\svnobj" "Dev ice\Plc Logic\Application\Library Manager"
> Reverted 'Device\Plc Logic\Application\Library Manager\svnobj'
> Reverted 'Device\Plc Logic\Application\Library Manager'I'm using the latest 
> SharpSVN build 1.7002.2011, and command line 1.7.2 (r1207936)
> 
> C:\{...}\svnwc>svn status
> D   Device\Plc Logic\Application\Library Manager\svnobj
> 
> I guess that this was the reason why I initially sorted the arguments to 
> revert by "parents first"...
> 
> I always thought of operations like "revert" or "commit" to work on a set of 
> input files, where the order of arguments is not important, but this seems to 
> be wrong :-(
> 
> Best regards

The problem is that the code checking the specified depth is called
in the context of processing a single target from the target list.
It cannot know that you're also going to revert the single child.

Fixing this would require changing how libsvn_wc processes arguments
for revert, and changing at least one public function (svn_wc_revert4).

I suppose we could add a workaround at the client layer that updates
the specified depth to inifinity if all specified targets within the
specified depth result in the entire subtree being reverted.
Not sure if that isn't a bit too hackish, though.

In any case, I think this warrants an entry in our issue tracker,
if only because the behaviour can be confusing.

RE: Upgrade Subversion 1.4.3

[James Boden]

Andy, what do you mean svadmin dump/load route?  Is this for the repositories?  
Sorry for being dense here, I just mainly use the software and not do a lot of 
maintenance to it.

James Boden
IT Specialist
Western Regional Center for Correctional Ed
18415 Roxbury Road
Hagerstown, Md. 21740
301-766-9443
jbo...@dllr.state.md.us


From: Andy Levy [andy.l...@gmail.com]
Sent: Wednesday, February 01, 2012 11:51 AM
To: James Boden
Cc: Giulio Troccoli; Stefan Sperling; users@subversion.apache.org
Subject: Re: Upgrade Subversion 1.4.3

On Wed, Feb 1, 2012 at 11:32, James Boden  wrote:
> So if I get this right, I do not have to upgrade each step, I can jump to the 
> 1.7.2 version.  Is there an installer for this?

yes, you can jump straight from 1.4 to 1.7 (though I'd recommend going
the svadmin dump/load route to take advantage of enhancements to
repository storage across your whole history).

There are a number of distributions available, both from
companies/individuals (CollabNet, WANDisco, etc.) and OS
distributions. What is available to you and how the installation
process gets run will depend upon what OS your server is running and
what distribution you select.

> 
> From: Giulio Troccoli [giulio.trocc...@mediatelgroup.co.uk]
> Sent: Wednesday, February 01, 2012 11:27 AM
> To: James Boden
> Cc: Stefan Sperling; users@subversion.apache.org
> Subject: Re: Upgrade Subversion 1.4.3
>
> On 01/02/12 15:58, James Boden wrote:
>> Ok, I reviewed the release-notes.  My question is do I have to upgrade to 
>> 1.5 then 1.6 and then 1.7.2?If this is the case where is the installer 
>> for these versions?  Also what about the information I currently have stored 
>> in the repositories.  According to the release-notes they will be 
>> automatically upgraded, if I am understanding correctly.
>>
>
> Actually the Working Copies are automatically upgraded when "touched"
> for the first time by the new version. The Repositories are NOT
> automatically upgraded, but it's a manual step through svnadmin upgrade
> (which mean *you* decide if and when to upgrade the repository).
>
> Giulio

Re: Upgrade Subversion 1.4.3

[Andy Levy]

On Wed, Feb 1, 2012 at 11:32, James Boden  wrote:
> So if I get this right, I do not have to upgrade each step, I can jump to the 
> 1.7.2 version.  Is there an installer for this?

yes, you can jump straight from 1.4 to 1.7 (though I'd recommend going
the svadmin dump/load route to take advantage of enhancements to
repository storage across your whole history).

There are a number of distributions available, both from
companies/individuals (CollabNet, WANDisco, etc.) and OS
distributions. What is available to you and how the installation
process gets run will depend upon what OS your server is running and
what distribution you select.

> 
> From: Giulio Troccoli [giulio.trocc...@mediatelgroup.co.uk]
> Sent: Wednesday, February 01, 2012 11:27 AM
> To: James Boden
> Cc: Stefan Sperling; users@subversion.apache.org
> Subject: Re: Upgrade Subversion 1.4.3
>
> On 01/02/12 15:58, James Boden wrote:
>> Ok, I reviewed the release-notes.  My question is do I have to upgrade to 
>> 1.5 then 1.6 and then 1.7.2?    If this is the case where is the installer 
>> for these versions?  Also what about the information I currently have stored 
>> in the repositories.  According to the release-notes they will be 
>> automatically upgraded, if I am understanding correctly.
>>
>
> Actually the Working Copies are automatically upgraded when "touched"
> for the first time by the new version. The Repositories are NOT
> automatically upgraded, but it's a manual step through svnadmin upgrade
> (which mean *you* decide if and when to upgrade the repository).
>
> Giulio

Re: Upgrade Subversion 1.4.3

[Andy Levy]

On Wed, Feb 1, 2012 at 11:27, Giulio Troccoli
 wrote:
>
>
> On 01/02/12 15:58, James Boden wrote:
>>
>> Ok, I reviewed the release-notes.  My question is do I have to upgrade to
>> 1.5 then 1.6 and then 1.7.2?    If this is the case where is the installer
>> for these versions?  Also what about the information I currently have stored
>> in the repositories.  According to the release-notes they will be
>> automatically upgraded, if I am understanding correctly.
>>
>
> Actually the Working Copies are automatically upgraded when "touched" for
> the first time by the new version. The Repositories are NOT automatically
> upgraded, but it's a manual step through svnadmin upgrade (which mean *you*
> decide if and when to upgrade the repository).

Working copies are not automatically upgraded by the 1.7 clients. You
have to manually upgrade them (svn upgrade).

Pre-1.7 clients do automatically upgrade the WC format.

Sorry Giulio, I forgot Reply All the first time.

RE: Upgrade Subversion 1.4.3

[James Boden]

So if I get this right, I do not have to upgrade each step, I can jump to the 
1.7.2 version.  Is there an installer for this?

James Boden
IT Specialist
Western Regional Center for Correctional Ed
18415 Roxbury Road
Hagerstown, Md. 21740
301-766-9443
jbo...@dllr.state.md.us


From: Giulio Troccoli [giulio.trocc...@mediatelgroup.co.uk]
Sent: Wednesday, February 01, 2012 11:27 AM
To: James Boden
Cc: Stefan Sperling; users@subversion.apache.org
Subject: Re: Upgrade Subversion 1.4.3

On 01/02/12 15:58, James Boden wrote:
> Ok, I reviewed the release-notes.  My question is do I have to upgrade to 1.5 
> then 1.6 and then 1.7.2?If this is the case where is the installer for 
> these versions?  Also what about the information I currently have stored in 
> the repositories.  According to the release-notes they will be automatically 
> upgraded, if I am understanding correctly.
>

Actually the Working Copies are automatically upgraded when "touched"
for the first time by the new version. The Repositories are NOT
automatically upgraded, but it's a manual step through svnadmin upgrade
(which mean *you* decide if and when to upgrade the repository).

Giulio

Re: Upgrade Subversion 1.4.3

[Giulio Troccoli]

On 01/02/12 15:58, James Boden wrote:

Ok, I reviewed the release-notes.  My question is do I have to upgrade to 1.5 
then 1.6 and then 1.7.2?If this is the case where is the installer for 
these versions?  Also what about the information I currently have stored in the 
repositories.  According to the release-notes they will be automatically 
upgraded, if I am understanding correctly.



Actually the Working Copies are automatically upgraded when "touched" 
for the first time by the new version. The Repositories are NOT 
automatically upgraded, but it's a manual step through svnadmin upgrade 
(which mean *you* decide if and when to upgrade the repository).


Giulio

Re: Upgrade Subversion 1.4.3

[Thorsten Schöning]

Guten Tag James Boden,
am Mittwoch, 1. Februar 2012 um 16:58 schrieben Sie:

> My question is do I have to
> upgrade to 1.5 then 1.6 and then 1.7.2?

No, because it's just binaries and your repositories aren't touch
during installation of newer versions.

> Also what about the
> information I currently have stored in the repositories.  According
> to the release-notes they will be automatically upgraded, if I am 
> understanding correctly.

Where did you read that? My understanding always was that nothing
happens with the repositories unless you do either svnadmin upgrade
which does the minimal amount of wirk for your repository to be able
to use newer featuresor svnadmin dump/load cycle where completely new
repos can be created and benefit of deduplicated binaries and all that
new stuff.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon.030-2 1001-310
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow

Re: Upgrade Subversion 1.4.3

[Nico Kadel-Garcia]

On Wed, Feb 1, 2012 at 10:58 AM, James Boden  wrote:
> Ok, I reviewed the release-notes.  My question is do I have to upgrade to 1.5 
> then 1.6 and then 1.7.2?    If this is the case where is the installer for 
> these versions?  Also what about the information I currently have stored in 
> the repositories.  According to the release-notes they will be automatically 
> upgraded, if I am understanding correctly.

You shouldn't *have* to do intervening upgrades. But I strongly
encourage you to do thorough backups before proceeding, especially on
the server.

And where the installer is depends on what OS you are working on.
CygWin and TortoiseSVN for Windows have up-to-date releases. Old Linux
releases, such as RHEL 4, are probably never going to get an
up-to-date release. because the dependencies have changed too much.
RHEL 5 and 6, I'm trying to set up a github repo for source code to
submit to repoforge, but have been a bit busy lately. (Don't ask.)

RE: Upgrade Subversion 1.4.3

[James Boden]

Ok, I reviewed the release-notes.  My question is do I have to upgrade to 1.5 
then 1.6 and then 1.7.2?If this is the case where is the installer for 
these versions?  Also what about the information I currently have stored in the 
repositories.  According to the release-notes they will be automatically 
upgraded, if I am understanding correctly.

James Boden
IT Specialist
Western Regional Center for Correctional Ed
18415 Roxbury Road
Hagerstown, Md. 21740
301-766-9443
jbo...@dllr.state.md.us


From: Stefan Sperling [s...@elego.de]
Sent: Wednesday, February 01, 2012 10:18 AM
To: James Boden
Cc: users@subversion.apache.org
Subject: Re: Upgrade Subversion 1.4.3

On Wed, Feb 01, 2012 at 02:38:36PM +, James Boden wrote:
> I would like to upgrade my subversion from 1.4.3 to the newest one.
> What is entailed to do this?

Hi James,

please see the release notes for each release between 1.4 and the
release you're upgrading to (I'd recommend using the latest patch
release in the 1.7 series, currently 1.7.2):
http://subversion.apache.org/docs/release-notes/

The release notes discuss implications of each release upgrade
in great detail. If you have any open questions after reading these
notes please don't hesitate to post to this list again for answers.

Good luck!

Problem with reverting

[Markus Schaber]

Hi,

I have a directory foo with tree conflict: local add of foo and a file foo/bar, 
and then an update trying to add the same foo and foo/bar. Now, I try to revert 
using SharpSVN, which internally calls svn_client_revert_2(). I give the path 
of the directory and the file, and a depth of "files". Then I get the Exception 
Can't revert 'C:\Users\{...}\foo' without reverting children", 
SVN_ERR_WC_INVALID_OPERATION_DEPTH. 

I can reproduce that on the command line, getting the additional hint that I 
should use --depth="infinity" instead. That seems to indicate that reverts of 
added directories always need --depth="infinity", despite the fact that all 
existing children are also mentioned in the argument list.

C:\{...}\svnwc>svn status
R C Device\Plc Logic\Application\Library Manager
  >   local add, incoming add upon update
A   Device\Plc Logic\Application\Library Manager\svnobj
Summary of conflicts:
  Tree conflicts: 1

C:\{...}\svnwc>svn revert --depth=files "Device\Plc Logic\Application\Library 
Manager" "Device\Plc  Logic\Application\Library Manager\svnobj"
svn: E155038: Try 'svn revert --depth infinity' instead?
svn: E155038: Can't revert 'C:\{...}\svnwc\Device\Plc Logic\Application\Library 
Manager' without r everting children


The strange thing is that if I change the order of arguments, it works without 
errors, but misses to restore the "svnobj" file from the repository, marking it 
as "deleted" - despite the fact that both --depth=files and the file's path are 
given on the command line.

C:\{...}\svnwc>svn revert --depth=files "Device\Plc Logic\Application\Library 
Manager\svnobj" "Dev ice\Plc Logic\Application\Library Manager"
Reverted 'Device\Plc Logic\Application\Library Manager\svnobj'
Reverted 'Device\Plc Logic\Application\Library Manager'I'm using the latest 
SharpSVN build 1.7002.2011, and command line 1.7.2 (r1207936)

C:\{...}\svnwc>svn status
D   Device\Plc Logic\Application\Library Manager\svnobj

I guess that this was the reason why I initially sorted the arguments to revert 
by "parents first"...

I always thought of operations like "revert" or "commit" to work on a set of 
input files, where the order of arguments is not important, but this seems to 
be wrong :-(

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: Upgrade Subversion 1.4.3

[Stefan Sperling]

On Wed, Feb 01, 2012 at 02:38:36PM +, James Boden wrote:
> I would like to upgrade my subversion from 1.4.3 to the newest one.
> What is entailed to do this?

Hi James,

please see the release notes for each release between 1.4 and the
release you're upgrading to (I'd recommend using the latest patch
release in the 1.7 series, currently 1.7.2):
http://subversion.apache.org/docs/release-notes/

The release notes discuss implications of each release upgrade
in great detail. If you have any open questions after reading these
notes please don't hesitate to post to this list again for answers.

Good luck!

Re: Upgrade Subversion 1.4.3

[Giulio Troccoli]

On 01/02/12 14:38, James Boden wrote:


I would like to upgrade my subversion from 1.4.3 to the newest one.  
What is entailed to do this?


Thanks




Do you want to upgrade the server, client or both? On what system(s)? If 
you would like to upgrade the server, do you want to upgrade the 
repositories too?


G

Upgrade Subversion 1.4.3

[James Boden]

I would like to upgrade my subversion from 1.4.3 to the newest one.  What is 
entailed to do this?



Thanks



James Boden
IT Specialist
Western Regional Center for Correctional Ed
18415 Roxbury Road
Hagerstown, Md. 21740
301-766-9443
jbo...@dllr.state.md.us

Re: check-mime-type, Windows client, non-ASCII path

[Ulrich Eckhardt]

Am 01.02.2012 09:00, schrieb Ignacio González (Eliop):

Clients: Windows-XP, Windows 7, svn 1.6.16 (Spanish)


Just to make sure, are you using a native MS Windows client or are you 
using Cygwin? Also, the clients differ slightly depending on the 
distribution, it would be helpful to have those, too.



Path name (in Windows, client): C:\Usuarios\arenero\Inútil.TXT
(note the u with an acute accent: ú)

C:\Usuarios\arenero>svn ci acentos -m "Prueba 1"
Adding acentos
Adding acentos\In£til.TXT


Hmmm. Here something already failed, the accented u changed to a pound 
sign. Or is that just a transmission error, caused by email?




Transmitting file data .svn: Commit failed (details follow):
svn: Commit blocked by pre-commit hook (exit code 1) with output:
/opt/csvn/data/repositories/telecontrol/hooks/check-mime-type:
`/opt/csvn/bin/sv
nlook proplist /opt/csvn/data/repositories/arenero -t 44-1e --verbose
acentos/In
?\195?\186til.TXT' failed with this output:
svnlook: Path 'acentos/In?\195?\186til.TXT' does not exist


Just for the record, I guess the ?\195?\186 could be a representation 
derived from the byte values of UTF-8, but I haven't verified that. What 
I'm not 100% sure is whether that is a fault in the hook script and how 
it handles those arguments. It would be interesting to know if this 
works with the hook script active.




To help diagnose it, I tried to check out an already existing file with
accents in its name (checked in before the Hook "check-mime-type" (bash)
was added in the server).
Check out fails.


That shouldn't happen, no matter what the hook scripts say. What exactly 
is the error? What is the name of the file?


The only reason I could imagine is when you somehow got a path into the 
repository that is invalid UTF-8. While checking out that path, the 
client would then try to transcode the UTF-8 to MS Windows' native 
UTF-16 and fail. I believe some older SVNs relied on the client sending 
well-formed UTF-8, instead of validating it server-side. With the client 
being less than perfect, this could then lead to invalid paths. How old 
is your repository? Can you back it up and run svnadmin verify on it?


That said, I have been using lots of different characters (extended 
Latin, Greek, Chinese, Japanese, Indian) inside a Linux-hosted repo, 
accessed via svnserve by clients on MS Windows XP and 7 without any 
issues. The warning by Nico IMHO only applies if you want to share 
working copies between different systems, which is discouraged anyway, 
but those problems are actually not specific to SVN.



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: new folder

[Alan Barrett]

On Wed, 01 Feb 2012, sureshkumar nandakumar wrote:

I want to prevent commits in /branches alone.
Apart from admin, no one shouldn't add any new folders under in
/branches folder.

Already We are using svnperm for access control. Can u guide me, how I
can do this?


svnperms.py can already do this, and the examples in 
svnperms.conf.example are very close to your use case.  
See "example1" in 
, 
where it says that only members of group3 can create tags, and 
adapt it so that only members of your admin group can create 
branches.


--apb (Alan Barrett)

Re: check-mime-type, Windows client, non-ASCII path

[Nico Kadel-Garcia]

2012/2/1 Ignacio González (Eliop) :
> Clients: Windows-XP, Windows 7, svn 1.6.16 (Spanish)
> Server: Linux (CentOS), svn 1.6.16 (Spanish)
>
> Repository created OK
> Hundreds of revisions already checked-in OK
> Hook "check-mime-type" (bash) added in server
> A couple of revisions checked-in OK
> New file added with non-ASCII characters -> Problem:
> Path name (in Windows, client): C:\Usuarios\arenero\Inútil.TXT
> (note the u with an acute accent: ú)
>
> C:\Usuarios\arenero>svn ci acentos -m "Prueba 1"
> Adding         acentos
> Adding         acentos\In£til.TXT
> Transmitting file data .svn: Commit failed (details follow):
> svn: Commit blocked by pre-commit hook (exit code 1) with output:
> /opt/csvn/data/repositories/telecontrol/hooks/check-mime-type:
> `/opt/csvn/bin/sv
> nlook proplist /opt/csvn/data/repositories/arenero -t 44-1e --verbose
> acentos/In
> ?\195?\186til.TXT' failed with this output:
> svnlook: Path 'acentos/In?\195?\186til.TXT' does not exist
>
> To help diagnose it, I tried to check out an already existing file with
> accents in its name
> (checked in before the Hook "check-mime-type" (bash) was added in the
> server).
> Check out fails.
> Oh, my God.
>
> Suggestions ?

First, avoid non-ascii characters in file names. It causes real
problems with pre-commit hooks and post-commit hooks that do not
properly quote their arguments, and that's not something you can
handle on the client side. And I've had network file shares used for
working copies, such as NetApp serviced home directories NFS mounted
as /home/$USER on the Linux side and CIFS mounted $HOMEDIR on the
Windows side, where people generated files on the Windows side,
successfully checked them in, and couldn't successfully read or delete
the files on the Linux NFS side because the server hadn't been set up
with UTF compatible NetApp filesystems.

Second, can you check out the *directory* that ocntains the file by
using the directory name, and letting the client deal with the
wackiness? And can you use 'svn mv', or do your operations with a
TortoiseSVN client, which is really handy for getting files with funny
names correctly processed?

Re: new folder

[sureshkumar nandakumar]

Hi Allan,

I want to prevent commits in /branches alone.
Apart from admin, no one shouldn't add any new folders under in
/branches folder.

Already We are using svnperm for access control. Can u guide me, how I
can do this?
If possible share your pre-commit script and guide me how i can modify
the script, based on my requirement.


On 2/1/12, Campbell Allan  wrote:
>
> On Monday 23 January 2012, sureshkumar nandakumar wrote:
>> Hi,
>>
>> I would like to restrict new folder creation under in /branches.
>> Currently we are using SVN perm files for restrict the read/write
>> access control.
>> We have around 1000 SVN users, we are in position to control the access
>> level.
>>
>> Without our knowledge no one should not add any new folders under in
>> /branches directory.
>> Can anyone suggest me, how can i do this and how to get alert, if any
>> new folder is created
>
> I suppose this is tricky if you disregard other options of control. To be
> honest, it isn't clear what you require from your message. Whether it's a
> social solution you want to use and only get notification when a commit to
> the
> branches directory occurs or if you want to prevent commits. The former I'd
> use a simple post-commit email notification script.
>
> To prevent commits I'd implement a pre-commit hook that restricts commits to
> the branches directory unless the user and path are in a configuration file.
> I'd go a bit further and add time based control to this too so that the
> window
> for committing is limited. I'd place the configuration file in a separate
> repository whose access you can completely control and have a post commit
> script to export the file on the server. This allows for an audit and
> history
> trail to be made.
>
> --
>
> Sword Ciboodle
> www.sword-ciboodle.com
>
> t +44 141 533 4000
>
> www.sword-group.com
> __
> Sword Ciboodle is the trading name of ciboodle Limited (a company
> registered in Scotland with registered number SC143434 and whose
> registered office is at India of Inchinnan, Renfrewshire, UK,
> PA4 9LH) which is part of the Sword Group of companies.
>
> This email (and any attachments) is intended for the named
> recipient(s) and is private and confidential. If it is not for you,
> please inform us and then delete it. If you are not the intended
> recipient(s), the use, disclosure, copying or distribution of any
> information contained within this email is prohibited. Messages to
> and from us may be monitored. If the content is not about the
> business of the Sword Group then the message is neither from nor
> sanctioned by us.
>
> Internet communications are not secure. You should scan this
> message and any attachments for viruses. Under no circumstances
> do we accept liability for any loss or damage which may result from
> your receipt of this email or any attachment.
> __
>
>

Re: new folder

[Campbell Allan]

On Monday 23 January 2012, sureshkumar nandakumar wrote:
> Hi,
> 
> I would like to restrict new folder creation under in /branches.
> Currently we are using SVN perm files for restrict the read/write
> access control.
> We have around 1000 SVN users, we are in position to control the access
> level.
> 
> Without our knowledge no one should not add any new folders under in
> /branches directory.
> Can anyone suggest me, how can i do this and how to get alert, if any
> new folder is created

I suppose this is tricky if you disregard other options of control. To be 
honest, it isn't clear what you require from your message. Whether it's a 
social solution you want to use and only get notification when a commit to the 
branches directory occurs or if you want to prevent commits. The former I'd 
use a simple post-commit email notification script. 

To prevent commits I'd implement a pre-commit hook that restricts commits to 
the branches directory unless the user and path are in a configuration file. 
I'd go a bit further and add time based control to this too so that the window 
for committing is limited. I'd place the configuration file in a separate 
repository whose access you can completely control and have a post commit 
script to export the file on the server. This allows for an audit and history 
trail to be made.

-- 

Sword Ciboodle
www.sword-ciboodle.com

t +44 141 533 4000

www.sword-group.com
__
Sword Ciboodle is the trading name of ciboodle Limited (a company 
registered in Scotland with registered number SC143434 and whose 
registered office is at India of Inchinnan, Renfrewshire, UK, 
PA4 9LH) which is part of the Sword Group of companies.

This email (and any attachments) is intended for the named
recipient(s) and is private and confidential. If it is not for you, 
please inform us and then delete it. If you are not the intended 
recipient(s), the use, disclosure, copying or distribution of any 
information contained within this email is prohibited. Messages to 
and from us may be monitored. If the content is not about the 
business of the Sword Group then the message is neither from nor 
sanctioned by us.

Internet communications are not secure. You should scan this
message and any attachments for viruses. Under no circumstances
do we accept liability for any loss or damage which may result from
your receipt of this email or any attachment.
__

check-mime-type, Windows client, non-ASCII path

[Eliop]

Clients: Windows-XP, Windows 7, svn 1.6.16 (Spanish)
Server: Linux (CentOS), svn 1.6.16 (Spanish)

Repository created OK
Hundreds of revisions already checked-in OK
Hook "check-mime-type" (bash) added in server
A couple of revisions checked-in OK
New file added with non-ASCII characters -> Problem:
Path name (in Windows, client): C:\Usuarios\arenero\Inútil.TXT
(note the u with an acute accent: ú)

C:\Usuarios\arenero>svn ci acentos -m "Prueba 1"
Adding acentos
Adding acentos\In£til.TXT
Transmitting file data .svn: Commit failed (details follow):
svn: Commit blocked by pre-commit hook (exit code 1) with output:
/opt/csvn/data/repositories/telecontrol/hooks/check-mime-type:
`/opt/csvn/bin/sv
nlook proplist /opt/csvn/data/repositories/arenero -t 44-1e --verbose
acentos/In
?\195?\186til.TXT' failed with this output:
svnlook: Path 'acentos/In?\195?\186til.TXT' does not exist

To help diagnose it, I tried to check out an already existing file with
accents in its name
(checked in before the Hook "check-mime-type" (bash) was added in the
server).
Check out fails.
Oh, my God.

Suggestions ?
-- 
Ignacio Gonzalez T.