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

Re: new folder

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

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 <campbell.allan <at> sword-ciboodle.com> 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: check-mime-type, Windows client, non-ASCII path

2012/2/1 Ignacio González (Eliop) <igtorque.eliop <at> googlemail.com>:
> 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

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

<https://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/svnperms.conf.example>, 
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

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.
**************************************************************************************

Upgrade Subversion 1.4.3

Re: Upgrade Subversion 1.4.3

Re: Upgrade Subversion 1.4.3

On Wed, Feb 01, 2012 at 02:38:36PM +0000, 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

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.schaber <at> 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