restrict permissions for creating/deleting branches and tags

[Nadia Anastopoulou]

Dear support,



I want to know If from subversion I can restrict the permissions from 
developers to create/remove branches and tags. We need to give the permission 
to developers only to work on the main development trunk and only authorized 
persons should create/delete branches and tags.

Is this possible?



Thank you in advance,

Nadia Anastopoulou
Database Administrator

Information Systems Department
MedNet International Ltd www.mni.gr
Tel. (+30) 210 6141365
Fax (+30) 210 6141366
Email: nanas...@mni.gr

Re: restrict permissions for creating/deleting branches and tags

[vishwajeet singh]

you can accomplish that by using pre-commit hooks

On Fri, Jul 9, 2010 at 1:30 PM, Nadia Anastopoulou  wrote:

>  Dear support,
>
>
>
> I want to know If from subversion I can restrict the permissions from
> developers to create/remove branches and tags. We need to give the
> permission to developers only to work on the main development trunk and only
> authorized persons should create/delete branches and tags.
>
> Is this possible?
>
>
>
> Thank you in advance,
>
> *Nadia Anastopoulou**
> **Database Administrator*
>
> Information Systems Department
> MedNet International Ltd www.mni.gr
> Tel. (+30) 210 6141365
> Fax (+30) 210 6141366
> Email: nanas...@mni.gr
>
>
>
>
> __ Information from ESET NOD32 Antivirus, version of virus
> signature database 5263 (20100708) __
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>



-- 
Vishwajeet Singh
+91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com
Twitter: http://twitter.com/vishwajeets | LinkedIn:
http://www.linkedin.com/in/singhvishwajeet

Re: Checksum mismatch creating repository?

[Ulrich Eckhardt]

On Friday 09 July 2010, Arivan S. Bastos wrote:
> This week, the disk of our server burned and then we decided to upgrade the
> windows 2008 server to Windows Server 2008 R2.
>
> After the upgrade we are facing problem with the use of Subversion.
> We try to use VisualSVN 2.1.2 and CollabNet 1.6.12, and also tried going
> back to version 1.4.6 (the version we used before the OS update), but
> always facing the same error:
>
> "error: svn: Checksum mismatch for #FILENAME#"

Is this a verbatim copy of the error or is this for various values of 
#FILENAME#?

> The error happens when creating the repository using the command "svn
> import" to add

Wait: Why are you importing anything there? When migrating servers, I'd use 
the following steps:
1. Create dumpfiles on the old machine (this is part of the daily backup, 
actually) and save the configuration (conf/ subdir of the repository).
2. If the SVN versions are similar, copy the repository to the new machine. 
Otherwise, load the dumpfile into an empty repository and restore the 
configuration.
3. If the machine's hostname/IP isn't the same as the old one, convert working 
copies using "svn switch --relocate".

Of course, importing can be part of the normal workflow, too, but then I'd 
wonder if other operations on the new repository work, i.e. if it is only 
imports that fail.

> , and always seems to occur in large files over 100Mb. If we insist on
> trying to send the file, sometimes it is sent. However, when trying to
> perform the checkout (on client side) we got"cannot read chunk size"
> somewhere in the checkout, and looking at the apache log, we see the
> same "Checksum mismatch".
>
> Using the same version of subversion, performing the same procedures on the
> same files on a computer running windows 7, this error does not occur.

Actually, I'm still not sure what exactly you did and on what machines. One 
additional way to circle in the problem would be to access the repository 
using direct file:// access.

> It seems that there is some limitation of use of resources, because this
> seems to happens with large files only.

I'm not running Apache here, but I seem to remember some kind of timeout there 
from a recent discussion. Obviously, using a large file or a slow connection 
it needs more time and thus also takes you closer to that timeout.

Uli

-- 
ML: http://subversion.tigris.org/mailing-list-guidelines.html
FAQ: http://subversion.tigris.org/faq.html
Docs: http://svnbook.red-bean.com/

Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
   Visit our website at 
**
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. Sator Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

Re: Checksum mismatch creating repository?

[Arivan S. Bastos]

1) "Is this a verbatim copy of the error or is this for various values of
#FILENAME#?"
Various values.

2) "Why are you importing anything there?"
We cant use a dump file, cause we dont have it. But I think it is not
important, because the 'import' should work.

3) "Actually, I'm still not sure what exactly you did and on what machines."
a. I installed subversion
b. used "svnadmin create name # #"
c. used svn import-m "message" http:// servername # # / # # name /
Simple! This steps work on a Windows 7 Machine!

Thank u


2010/7/9 Ulrich Eckhardt 

> On Friday 09 July 2010, Arivan S. Bastos wrote:
> > This week, the disk of our server burned and then we decided to upgrade
> the
> > windows 2008 server to Windows Server 2008 R2.
> >
> > After the upgrade we are facing problem with the use of Subversion.
> > We try to use VisualSVN 2.1.2 and CollabNet 1.6.12, and also tried going
> > back to version 1.4.6 (the version we used before the OS update), but
> > always facing the same error:
> >
> > "error: svn: Checksum mismatch for #FILENAME#"
>
> Is this a verbatim copy of the error or is this for various values of
> #FILENAME#?
>
> > The error happens when creating the repository using the command "svn
> > import" to add
>
> Wait: Why are you importing anything there? When migrating servers, I'd use
> the following steps:
> 1. Create dumpfiles on the old machine (this is part of the daily backup,
> actually) and save the configuration (conf/ subdir of the repository).
> 2. If the SVN versions are similar, copy the repository to the new machine.
> Otherwise, load the dumpfile into an empty repository and restore the
> configuration.
> 3. If the machine's hostname/IP isn't the same as the old one, convert
> working
> copies using "svn switch --relocate".
>
> Of course, importing can be part of the normal workflow, too, but then I'd
> wonder if other operations on the new repository work, i.e. if it is only
> imports that fail.
>
> > , and always seems to occur in large files over 100Mb. If we insist on
> > trying to send the file, sometimes it is sent. However, when trying to
> > perform the checkout (on client side) we got"cannot read chunk size"
> > somewhere in the checkout, and looking at the apache log, we see the
> > same "Checksum mismatch".
> >
> > Using the same version of subversion, performing the same procedures on
> the
> > same files on a computer running windows 7, this error does not occur.
>
> Actually, I'm still not sure what exactly you did and on what machines. One
> additional way to circle in the problem would be to access the repository
> using direct file:// access.
>
> > It seems that there is some limitation of use of resources, because this
> > seems to happens with large files only.
>
> I'm not running Apache here, but I seem to remember some kind of timeout
> there
> from a recent discussion. Obviously, using a large file or a slow
> connection
> it needs more time and thus also takes you closer to that timeout.
>
> Uli
>
> --
> ML: http://subversion.tigris.org/mailing-list-guidelines.html
> FAQ: http://subversion.tigris.org/faq.html
> Docs: http://svnbook.red-bean.com/
>
> Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
>
>
> **
> Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
>
> **
>   Visit our website at 
>
> **
> 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. Sator Laser GmbH ist für diese
> Folgen nicht verantwortlich.
>
> **
>
>

Re: Checksum mismatch creating repository?

[Arivan S. Bastos]

I'll try using direct file:// access!

2010/7/9 Arivan S. Bastos 

> 1) "Is this a verbatim copy of the error or is this for various values of
> #FILENAME#?"
> Various values.
>
> 2) "Why are you importing anything there?"
> We cant use a dump file, cause we dont have it. But I think it is not
> important, because the 'import' should work.
>
> 3) "Actually, I'm still not sure what exactly you did and on what
> machines."
> a. I installed subversion
> b. used "svnadmin create name # #"
> c. used svn import-m "message" http:// servername # # / # # name /
> Simple! This steps work on a Windows 7 Machine!
>
> Thank u
>
>
> 2010/7/9 Ulrich Eckhardt 
>
> On Friday 09 July 2010, Arivan S. Bastos wrote:
>> > This week, the disk of our server burned and then we decided to upgrade
>> the
>> > windows 2008 server to Windows Server 2008 R2.
>> >
>> > After the upgrade we are facing problem with the use of Subversion.
>> > We try to use VisualSVN 2.1.2 and CollabNet 1.6.12, and also tried going
>> > back to version 1.4.6 (the version we used before the OS update), but
>> > always facing the same error:
>> >
>> > "error: svn: Checksum mismatch for #FILENAME#"
>>
>> Is this a verbatim copy of the error or is this for various values of
>> #FILENAME#?
>>
>> > The error happens when creating the repository using the command "svn
>> > import" to add
>>
>> Wait: Why are you importing anything there? When migrating servers, I'd
>> use
>> the following steps:
>> 1. Create dumpfiles on the old machine (this is part of the daily backup,
>> actually) and save the configuration (conf/ subdir of the repository).
>> 2. If the SVN versions are similar, copy the repository to the new
>> machine.
>> Otherwise, load the dumpfile into an empty repository and restore the
>> configuration.
>> 3. If the machine's hostname/IP isn't the same as the old one, convert
>> working
>> copies using "svn switch --relocate".
>>
>> Of course, importing can be part of the normal workflow, too, but then I'd
>> wonder if other operations on the new repository work, i.e. if it is only
>> imports that fail.
>>
>> > , and always seems to occur in large files over 100Mb. If we insist on
>> > trying to send the file, sometimes it is sent. However, when trying to
>> > perform the checkout (on client side) we got"cannot read chunk size"
>> > somewhere in the checkout, and looking at the apache log, we see the
>> > same "Checksum mismatch".
>> >
>> > Using the same version of subversion, performing the same procedures on
>> the
>> > same files on a computer running windows 7, this error does not occur.
>>
>> Actually, I'm still not sure what exactly you did and on what machines.
>> One
>> additional way to circle in the problem would be to access the repository
>> using direct file:// access.
>>
>> > It seems that there is some limitation of use of resources, because this
>> > seems to happens with large files only.
>>
>> I'm not running Apache here, but I seem to remember some kind of timeout
>> there
>> from a recent discussion. Obviously, using a large file or a slow
>> connection
>> it needs more time and thus also takes you closer to that timeout.
>>
>> Uli
>>
>> --
>> ML: http://subversion.tigris.org/mailing-list-guidelines.html
>> FAQ: http://subversion.tigris.org/faq.html
>> Docs: http://svnbook.red-bean.com/
>>
>> Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
>> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
>>
>>
>> **
>> Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
>> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
>>
>> **
>>   Visit our website at 
>>
>> **
>> 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. Sator Laser GmbH ist für diese
>> Folgen nicht verantwortlich.
>>
>> **
>>
>>
>

Re: swapping the trunk and a branch

[Cory Riddell]

Uli,

On 7/8/2010 10:39 AM, Ulrich Eckhardt wrote:
>
> Other than that, what Les Mikesell said might be true, i.e. that you need to 
> dump/reload your repository in order to reap the benefits of newer server 
> versions. 
>   

Going to do a backup/dump/reload this weekend.

> There is one other way, and that is to simply put an empty folder into your 
> solution dir. You can then "svn switch" it to different targets, e.g. to 
> various released version or an experimental one. In any case, it would become 
> a separate project as mentioned above. The empty dir (or file) would then 
> only serve as a placeholder or reminder. It's a one-time manual setup 
> operation you will have to educate your colleagues about though.
>   

I like the switch idea. I think the end result is pretty much the same
as having an external, but since you have to manually do it, I think
everybody might be a little more aware of the repository organization.

Thanks for the advice. Funny how something that starts as an off-topic 
conversation can meander back on-topic.

Cory

Re: How to choose between svn & http?

[Nico Kadel-Garcia]

On Thu, Jul 8, 2010 at 10:31 PM, Alec Kloss  wrote:
> On 2010-07-08 17:04, David Brodbeck wrote:
>>
>> On Jul 8, 2010, at 4:49 PM, Nico Kadel-Garcia wrote:
>> > A local comparison is often best, especially when operating over HTTPS
>> > or svn+ssh for security reasons: Because of the continuing storage of
>> > HTTP/HTTPS/svn/SSH passwords in clear-text by the UNIX or Linux
>> > versions of Subversion, I don't trust anything but the svn+ssh public
>> > key based access for public use. Unfortunately, this does cause a
>> > noticeable performance hit.
>>
>> It's worth pointing out that the private key has to have a passphrase, for 
>> this to be a security improvement. Otherwise all you've accomplished is to 
>> leave the password-equivalent in ~/.ssh instead of in ~/.svn. ;)  I mention 
>> this only because a lot of the applications for SSH public keys involve 
>> passwordless login.
>>
> [chop]
>
> I feel a little like a broken record, but...
>
> using GSSAPI (or Negotiate for HTTPS) substantially reduces the security
> issues by integrating authentication into the rest of a managed
> single-sign-on system.  GSSAPI/Negotiate also has the feature of working
> in all four remote access protocols for Subversion.  The downside is
> difficulty in configuration and poor support in some (or many or perhaps
> all) binary distributions of Subversion.  I have to admit, I don't think
> very highly of ssh public-key authentication;  I have a hard time
> believing very many users or administrators carefully protect, rotate,
> and revoke RSA keys in a timely manner, which seems to me to
> substantially reduce the security of ssh public-key "infrastructure".

It's a longstanding problem. Much as Subversion on UNIX and Linux, by
default, allows the plaintext saving of passwords, the SSH key
management tools allow the saving of passphrase free keys.

GSSAPI is cool. It does take more setup work, and the default versions
of OpenSSH on many industry standard releases do not support it, nor
does the "stable" release of Putty. Various development versions do
permit this, but then the setup has to play well with the ownership of
the files on the server (which svn+ssh does by using a single
designated user) or for shared account access, the setting of the
correct username for logging (which svn+ssh key management does by
setting svnserve command line options).

Cannot use directories named "global" in svn:externals?

[Nico Kadel-Garcia]

I'm working with Subversion 1.6.11 and 1.6.12 on RHEL 5, and have
noticed an svn:externals issue. If I attempt to use a target directory
named "global", it breaks the checkout in various confusing ways. For
example:

svn proplist -v .


svn proplist -v .
Properties on '.':
  svn:externals
testsvn://testrepo/repo/test
globalsvn://testrepo/repo/global

svn update
Fetching external item into 'global'
svn: warning: Unrecognized format for the relative external URL 'test'

svn: warning: Error handling externals definition for 'global/^/test':
svn: warning: Unrecognized format for the relative external URL 'test'


I'm assuming that the issue is that "global" is a bad, bad name for
any directory in Subversion. Is this the case, or is it merely
svn:externals that has these issues?

Re: Checksum mismatch creating repository?

[Arivan S. Bastos]

Hi,

Using direct file:// access works with no errors, so, seems like a
http://service limit or some transfer error.

I do not think that can be any configuration of Apache, because as I said,
we installed the same subverion and make the same improt command on the same
files on Windows 7 and had no problems. We also try Visual SVN.

Perhaps some operate system configuration. Any suggestion?

2010/7/9 Arivan S. Bastos 

>
> I'll try using direct file:// access!
>
> 2010/7/9 Arivan S. Bastos 
>
> 1) "Is this a verbatim copy of the error or is this for various values of
>> #FILENAME#?"
>> Various values.
>>
>> 2) "Why are you importing anything there?"
>> We cant use a dump file, cause we dont have it. But I think it is not
>> important, because the 'import' should work.
>>
>> 3) "Actually, I'm still not sure what exactly you did and on what
>> machines."
>> a. I installed subversion
>> b. used "svnadmin create name # #"
>> c. used svn import-m "message" http:// servername # # / # # name /
>> Simple! This steps work on a Windows 7 Machine!
>>
>> Thank u
>>
>>
>> 2010/7/9 Ulrich Eckhardt 
>>
>> On Friday 09 July 2010, Arivan S. Bastos wrote:
>>> > This week, the disk of our server burned and then we decided to upgrade
>>> the
>>> > windows 2008 server to Windows Server 2008 R2.
>>> >
>>> > After the upgrade we are facing problem with the use of Subversion.
>>> > We try to use VisualSVN 2.1.2 and CollabNet 1.6.12, and also tried
>>> going
>>> > back to version 1.4.6 (the version we used before the OS update), but
>>> > always facing the same error:
>>> >
>>> > "error: svn: Checksum mismatch for #FILENAME#"
>>>
>>> Is this a verbatim copy of the error or is this for various values of
>>> #FILENAME#?
>>>
>>> > The error happens when creating the repository using the command "svn
>>> > import" to add
>>>
>>> Wait: Why are you importing anything there? When migrating servers, I'd
>>> use
>>> the following steps:
>>> 1. Create dumpfiles on the old machine (this is part of the daily backup,
>>> actually) and save the configuration (conf/ subdir of the repository).
>>> 2. If the SVN versions are similar, copy the repository to the new
>>> machine.
>>> Otherwise, load the dumpfile into an empty repository and restore the
>>> configuration.
>>> 3. If the machine's hostname/IP isn't the same as the old one, convert
>>> working
>>> copies using "svn switch --relocate".
>>>
>>> Of course, importing can be part of the normal workflow, too, but then
>>> I'd
>>> wonder if other operations on the new repository work, i.e. if it is only
>>> imports that fail.
>>>
>>> > , and always seems to occur in large files over 100Mb. If we insist on
>>> > trying to send the file, sometimes it is sent. However, when trying to
>>> > perform the checkout (on client side) we got"cannot read chunk size"
>>> > somewhere in the checkout, and looking at the apache log, we see the
>>> > same "Checksum mismatch".
>>> >
>>> > Using the same version of subversion, performing the same procedures on
>>> the
>>> > same files on a computer running windows 7, this error does not occur.
>>>
>>> Actually, I'm still not sure what exactly you did and on what machines.
>>> One
>>> additional way to circle in the problem would be to access the repository
>>> using direct file:// access.
>>>
>>> > It seems that there is some limitation of use of resources, because
>>> this
>>> > seems to happens with large files only.
>>>
>>> I'm not running Apache here, but I seem to remember some kind of timeout
>>> there
>>> from a recent discussion. Obviously, using a large file or a slow
>>> connection
>>> it needs more time and thus also takes you closer to that timeout.
>>>
>>> Uli
>>>
>>> --
>>> ML: http://subversion.tigris.org/mailing-list-guidelines.html
>>> FAQ: http://subversion.tigris.org/faq.html
>>> Docs: http://svnbook.red-bean.com/
>>>
>>> Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
>>> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
>>>
>>>
>>> **
>>> Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
>>> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
>>>
>>> **
>>>   Visit our website at 
>>>
>>> **
>>> 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. Sator L

Re: restrict permissions for creating/deleting branches and tags

[David Weintraub]

On Fri, Jul 9, 2010 at 3:00 AM, Nadia Anastopoulou  wrote:
> I want to know If from subversion I can restrict the permissions from
> developers to create/remove branches and tags. We need to give the
> permission to developers only to work on the main development trunk and only
> authorized persons should create/delete branches and tags.

I have a Perl script that can do this. The script allows you to
specify who has what permission to make changes in the repository and
on what files and directories. The scripts are controlled by a file
that specifies the permissions. You can define groups to make this
easier.

The older version of the scripts are well tested, but require a
non-standard Perl module. You can install this via CPAN.

I've recently rewrote the hooks. The new version no longer requires
non-standard Perl modules, and was rewritten in a more object oriented
manner to be easier to understand and maintain. However, the newer
version has not been as well tested. The older version has been used
by many people for years. The new one is, well, new and simply hasn't
been as thoroughly field tested.

The old set of hook scripts are at:
http://dl.dropbox.com/u/433257/old_svn_hooks.zip. The new set is at
http://dl.dropbox.com/u/433257/new_svn_hooks.zip.

You can read about Subversion pre-commit hooks at http://bit.ly/9OC7cW.


-- 
David Weintraub
qazw...@gmail.com

Re: Cannot use directories named "global" in svn:externals?

[David Weintraub]

On Fri, Jul 9, 2010 at 10:14 AM, Nico Kadel-Garcia  wrote:
> I'm working with Subversion 1.6.11 and 1.6.12 on RHEL 5, and have
> noticed an svn:externals issue. If I attempt to use a target directory
> named "global", it breaks the checkout in various confusing ways. For
> example:
>
> svn proplist -v .
> Properties on '.':
>  svn:externals
>    test    svn://testrepo/repo/test
>    global    svn://testrepo/repo/global
>
> svn update
> Fetching external item into 'global'
> svn: warning: Unrecognized format for the relative external URL 'test'
>

Nothing wrong with using global in a URL, does that directory exist on
your Subversion server?

-- 
David Weintraub
qazw...@gmail.com

Promting files from trunk to a specific tag

[Eramo, Mark]

I have a question.

In CVS, if I made changes to some files in the trunk, I could promote those 
into a specific tag. Is it possible to do the same in SVN?

I have a few files in the trunk that I want to promote to an existing tag 
without creating a new tag. Just curious if this is possible and how it is done.

Regards,
Mark

svn symlink support on windows

[mateuf]

Getting tired of reading svn doesn't properly do symlinks on windows
cause win doesn't support them. Can someone categorically claim mklink
on current windoze isn't  up to the job?
I know it is a command line and it requires admin rights. I don't bite
command line - just find an underlying API - if mklink does it
properly then any sw should be able to.
Are admin rights a problem? I'd imagine this must be quite a common
case for other scenarios on win. Surely this can be overcome?

Svn import

[aneeja gerard]

Hello,

   Will svn import command allow   special characters.  How to skip UTF error  
Followed by invalid UTF -8 sequence.
I guess these special characters are created if the locale is not set properly 
but unfotunately its set to en_US.UTF-8.
How can such files that has these characters be included via svn import command.

RE: svn symlink support on windows

[Bert Huijben]

> -Original Message-
> From: mateuf [mailto:mate...@googlemail.com]
> Sent: vrijdag 9 juli 2010 11:08
> To: users@subversion.apache.org
> Subject: svn symlink support on windows
> 
> Getting tired of reading svn doesn't properly do symlinks on windows
> cause win doesn't support them. Can someone categorically claim mklink
> on current windoze isn't  up to the job?
> I know it is a command line and it requires admin rights. I don't bite
> command line - just find an underlying API - if mklink does it
> properly then any sw should be able to.
> Are admin rights a problem? I'd imagine this must be quite a common
> case for other scenarios on win. Surely this can be overcome?

(See also several mails on this list about the same subject)

The (Windows Vista+) API also requires administrative privileges and more
importantly requires you tell tell if the symlink is going to point at a
file or at a directory while creating the symlink. And this information
isn't stored in subversion as on unix it can point to anything.

And nobody has come up with a good design to work around/with these issues.

Bert

Re: Promting files from trunk to a specific tag

[Les Mikesell]

On 7/9/2010 11:04 AM, Eramo, Mark wrote:

I have a question.

In CVS, if I made changes to some files in the trunk, I could promote
those into a specific tag. Is it possible to do the same in SVN?

I have a few files in the trunk that I want to promote to an existing
tag without creating a new tag. Just curious if this is possible and how
it is done.


The concept of a tag is somewhat different between cvs and subversion so 
you probably want to reconsider what you are trying to accomplish at a 
higher level.  In cvs a tag is basically a label associated with a 
file/revision and you need them to group a set together because there is 
no other way to do it.  In subversion a tag is a 'cheap' copy that is 
generally only needed to give a human-friendly name instead remembering 
the path/revision where it was copied from.  You can assemble grouping 
that don't appear elsewhere into tags, but by convention they normally 
aren't updated.  So for your last question about modifying an existing 
tag, yes it is possible but it is not the usual way to do things.  Tags 
are usually snapshot copies that aren't modified after creation.


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

svnadmin create over CIFS mount.

[Terry Dooher]

Hi all,

I'm currently re-working a backup script to use svnsync instead of hotcopy due 
to the amount of time the latter is taking. 

My svn server is Debian etch running svn 1.6.11 (from source), which mounts a 
Windows Server 2003 share using the CIFS driver (v. 1.45). I've been 
successfully running hotcopies over the same share for some time.

The script will try to create and initialise a destination if one doesn't 
already exist. This part seems to break on the command:
   svnadmin create /mnt/svnbackup/repo

I've tried it manually and every time it pauses for about 10 seconds before 
returning:
   svnadmin: database is locked
   
...after which it has created the following files:
repo
repo/db
repo/locks
repo/locks/db-logs.lock
repo/locks/db.lock
repo/README.txt


I can work around this by creating/initialising it locally and moving it into 
place, but this is less than ideal. Does 'svnadmin create' do anything 
interesting or expect some kind of behaviour from the filesystem it's writing 
to? 

Cheers,

Terry.

Re: Promting files from trunk to a specific tag

[Ryan Schmidt]

On Jul 9, 2010, at 11:49, Les Mikesell wrote:
> On 7/9/2010 11:04 AM, Eramo, Mark wrote:
>> 
>> In CVS, if I made changes to some files in the trunk, I could promote
>> those into a specific tag. Is it possible to do the same in SVN?
>> 
>> I have a few files in the trunk that I want to promote to an existing
>> tag without creating a new tag. Just curious if this is possible and how
>> it is done.
> 
> The concept of a tag is somewhat different between cvs and subversion so you 
> probably want to reconsider what you are trying to accomplish at a higher 
> level.  In cvs a tag is basically a label associated with a file/revision and 
> you need them to group a set together because there is no other way to do it. 
>  In subversion a tag is a 'cheap' copy that is generally only needed to give 
> a human-friendly name instead remembering the path/revision where it was 
> copied from.  You can assemble grouping that don't appear elsewhere into 
> tags, but by convention they normally aren't updated.  So for your last 
> question about modifying an existing tag, yes it is possible but it is not 
> the usual way to do things.  Tags are usually snapshot copies that aren't 
> modified after creation.

You may also want to read the chapter in the Subversion book for CVS users

http://svnbook.red-bean.com/nightly/en/svn.forcvs.html

Especially:

http://svnbook.red-bean.com/nightly/en/svn.forcvs.branches-and-tags.html

Re: Cannot use directories named "global" in svn:externals?

[Nico Kadel-Garcia]

On Fri, Jul 9, 2010 at 11:54 AM, David Weintraub  wrote:
> On Fri, Jul 9, 2010 at 10:14 AM, Nico Kadel-Garcia  wrote:
>> I'm working with Subversion 1.6.11 and 1.6.12 on RHEL 5, and have
>> noticed an svn:externals issue. If I attempt to use a target directory
>> named "global", it breaks the checkout in various confusing ways. For
>> example:
>>
>> svn proplist -v .
>> Properties on '.':
>>  svn:externals
>>    test    svn://testrepo/repo/test
>>    global    svn://testrepo/repo/global
>>
>> svn update
>> Fetching external item into 'global'
>> svn: warning: Unrecognized format for the relative external URL 'test'
>>
>
> Nothing wrong with using global in a URL, does that directory exist on
> your Subversion server?

It does. I tracked it down to a setting on the svn:externals of the
'global' directory itself, apparently from when I was creating the new
svn:externals setting, but it's tied to some other issues I'll address
separately.

Unclear syntax for relative addressing of svn:externals, on RHEL 5, subversion-1.6.12

[Nico Kadel-Garcia]

The allowable syntax for svn:externals is a bit unclear in the Redbook.

Shouldn't I be able to set the svn:external to point to a location in
my active repository, such as the below settings?

svn propset svn:externals "release-1 ^/tags/release-1" .

I seem to be able to set such values, but updating with such values
fails miserably with the subversino-1.6.12, published from RPMforge on
RHEL 5 (for reference to the version I'm using).

Re: Unclear syntax for relative addressing of svn:externals, on RHEL 5, subversion-1.6.12

[Ryan Schmidt]

On Jul 9, 2010, at 14:08, Nico Kadel-Garcia wrote:

> The allowable syntax for svn:externals is a bit unclear in the Redbook.
> 
> Shouldn't I be able to set the svn:external to point to a location in
> my active repository, such as the below settings?
> 
>svn propset svn:externals "release-1 ^/tags/release-1" .
> 
> I seem to be able to set such values, but updating with such values
> fails miserably with the subversino-1.6.12, published from RPMforge on
> RHEL 5 (for reference to the version I'm using).

Try

   svn propset svn:externals "^/tags/release-1 release-1" .

New - SVN rejects valid target path with cryptic error msg

[Mike Lewit]

Hi,

 

I am running a perl script that invokes svn merge commands and after
many 

merges, svn consistently rejected one particular file with a cryptic
path and a 

path not found message.

 

command issued in merge.pm:

svn merge --depth empty --non-interactive http://bby-

svn:3691/svn/projects/PM73232_01/trunk/srcve24x6g_diags/etc/ddr/readme.t
x...@62443

 http://bby-

svn:3691/svn/projects/PM73232_01/trunk/srcve24x6g_diags/etc/ddr/readme.t
x...@62735

 ./srcve24x6g_diags/etc/ddr/readme.txt

 

svn: '/svn/!svn/bc/62436/main/srcve24x6g_diags/etc/ddr/readme.txt' path
not 

found

 

I found a similiar error message in issue 3481. Anyone know what causes
SVN to 

sometimes reject a valid path? I ran thru 100+ merges before that and
the file 

is simple,no SVN properties. I requested a diff with TortoiseSVN and it
came 

back with the same error message. I rebooted and entered a manual
cmdline merge 

and it worked.

 

Thanks,

Mike

 

 

Re: Unclear syntax for relative addressing of svn:externals, on RHEL 5, subversion-1.6.12

[Nico Kadel-Garcia]

On Fri, Jul 9, 2010 at 4:19 PM, Ryan Schmidt
 wrote:
>
> On Jul 9, 2010, at 14:08, Nico Kadel-Garcia wrote:
>
>> The allowable syntax for svn:externals is a bit unclear in the Redbook.
>>
>> Shouldn't I be able to set the svn:external to point to a location in
>> my active repository, such as the below settings?
>>
>>    svn propset svn:externals "release-1 ^/tags/release-1" .
>>
>> I seem to be able to set such values, but updating with such values
>> fails miserably with the subversino-1.6.12, published from RPMforge on
>> RHEL 5 (for reference to the version I'm using).
>
> Try
>
>   svn propset svn:externals "^/tags/release-1 release-1" .

On Subversion 1.6? I think not, and tested such. The syntax described
at http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html
describes the precise reverse syntax, and it accepts this.

   svn propset svn:externals "release-1
svn://svnserver/repo/tags/release-1".

What I wanted to do was have Subversion check out directories from
within the same repository, rooted to the top of the repository, so
that moving a tag or branch up or down wouldn't break the references.
I'd thought from the documentation about 'relative references' that it
would apply to the URL of the external repository, so that if the repo
is checked out as file:///, https:///, svn:///, etc. the URL's for
svn:externals downloading would be auto-munged appropriately.

Is this not available?

Re: Unclear syntax for relative addressing of svn:externals, on RHEL 5, subversion-1.6.12

[Ryan Schmidt]

On Jul 9, 2010, at 17:13, Nico Kadel-Garcia wrote:
> On Fri, Jul 9, 2010 at 4:19 PM, Ryan Schmidt wrote:
>> On Jul 9, 2010, at 14:08, Nico Kadel-Garcia wrote:
>> 
>>> The allowable syntax for svn:externals is a bit unclear in the Redbook.
>>> 
>>> Shouldn't I be able to set the svn:external to point to a location in
>>> my active repository, such as the below settings?
>>> 
>>>svn propset svn:externals "release-1 ^/tags/release-1" .
>>> 
>>> I seem to be able to set such values, but updating with such values
>>> fails miserably with the subversino-1.6.12, published from RPMforge on
>>> RHEL 5 (for reference to the version I'm using).
>> 
>> Try
>> 
>>   svn propset svn:externals "^/tags/release-1 release-1" .
> 
> On Subversion 1.6? I think not, and tested such. The syntax described
> at http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html
> describes the precise reverse syntax, and it accepts this.
> 
>   svn propset svn:externals "release-1
> svn://svnserver/repo/tags/release-1".
> 
> What I wanted to do was have Subversion check out directories from
> within the same repository, rooted to the top of the repository, so
> that moving a tag or branch up or down wouldn't break the references.
> I'd thought from the documentation about 'relative references' that it
> would apply to the URL of the external repository, so that if the repo
> is checked out as file:///, https:///, svn:///, etc. the URL's for
> svn:externals downloading would be auto-munged appropriately.
> 
> Is this not available?

Yes, it is possible, using the syntax I provided.

On the book page you referred to, scroll down to the part that reads "As of 
Subversion 1.5, though, a new format of the svn:externals property is 
supported." The old externals syntax, which does not support what you want, had 
the format "localdir url". The new format, that does support what you want, has 
the format "url localdir" (the parameters are reversed from before). I know 
this works because I use it in my repository here:

http://code.google.com/p/canviz/source/checkout

You can check out a working copy and see it work for yourself, or see:

$ svn propget svn:externals http://canviz.googlecode.com/svn/canviz/trunk
^/vendor/excanvas/0...@7 excanvas
^/path/trunk/l...@262 path
^/vendor/prototype/1.6.0.3/d...@135 prototype

Perl API SVN::Ra::get_commit_editor2 causes TypeError

[Markus Kuhn]

I'm trying to commit a file modification in a Subversion repository from
within a Perl CGI script, and the Perl SVN:Ra API looks like the right tool
for doing that, but I have early on run into a problem:

Using subversion-perl-1.5.7 (from openSUSE Linux 11.1), the test program

#!/usr/bin/perl
use SVN::Core;
use SVN::Ra;
use SVN::Delta;
my $ra = SVN::Ra->new('http://core.svn.wordpress.org/');
my $logmsg = "test commit via the SVN:Ra Perl API";
sub commit_callback {
my ($arg) = @_;
use Data::Dumper;
print STDERR "commit_callback(".Dumper($arg).")\n";
}
my $editor = SVN::Delta::Editor->new(
$ra->get_commit_editor2($logmsg, \&commit_callback, undef, {}, 0));

results in the error message

  TypeError in method 'svn_ra_get_commit_editor2', argument 5 of type 
'svn_commit_callback2_t'

being printed.

Any idea what I am doing wrong?

I had thought, the last lines follow closely the example given in "man SVN::Ra":

   $ra->get_commit_editor($logmsg, $callback, $callback_baton, 
$lock_tokens, $keep_locks)
   $ra->get_commit_editor2($logmsg, $callback, $callback_baton, 
$lock_tokens, $keep_locks)
   Return an opaque editor object for committing a new revision to the 
repository.  The
   return values should be passed to the SVN::Delta::Editor constructor 
to create an
   editor object you can actually use.  For example:

   my $editor = SVN::Delta::Editor->new(
   $ra->get_commit_editor(
   "I'm going to commit some changes from within my Perl 
code.",
   \&commit_callback, undef, {}, 0));

   Now that you've got your editor you can call methods on it to 
describe changes in the
   tree you want to make, such as adding directories, changing file 
contents, etc.  See
   SVN::Delta for documentation of the editor interface.

   The $callback function will be called during your call to the 
"$ed->close_edit()"
   method, after the commit has succeeded.  It will not be called if 
there were no
   changes to commit.  If you don't need it, pass undef instead of a 
code ref.

   "get_commit_editor2" is identical to "get_commit_editor" except for 
the information
   passed to the callback function.  The new version, added in 
Subversion 1.4, will pass
   the callback a single value (TODO: I can' test this, but it's 
probably an object or
   hash ref) which contains all the information.  It also includes the 
error message
   from the post-commit hook script, which is not available with 
"get_commit_editor".

(The last TODO sentences above worry me somewhat: is this API actually ready 
for production use?)

Markus

-- 
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain