You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by dieter oberkofler <do...@gmail.com> on 2009/04/06 10:08:12 UTC

Default server based properties

Hi,
How would I force Subversion to set some default properties for all/some
files on the server side?
I would for example like to have all document files (either by extension or
for a directory) created with the "needs-lock" property.
Thank you,
D

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1560379

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

RE: Default server based properties

Posted by Bob Archer <bo...@amsi.com>.
You can use auto-props. But that is a client side feature not a server
side. I think the best practice is to use auto-props on the client and
use a pre-commit script on the server to ensure correct properties
exist. Your devs will be annoyed with the message that they will
eventually set up their autoprops. 

BOb


> -----Original Message-----
> From: dieter oberkofler [mailto:doberkofler.lists@gmail.com]
> Sent: Monday, April 06, 2009 10:50 AM
> To: 'Andy Levy'
> Cc: users@subversion.tigris.org
> Subject: RE: Default server based properties
> 
> Understood, but is there any way to force setting preferences instead
of
> just making sure that they are already set properly?
> Thank you,
> D
> 
> > -----Original Message-----
> > From: Andy Levy [mailto:andy.levy@gmail.com]
> > Sent: Monday, April 06, 2009 2:18 PM
> > To: doberkofler.lists@gmail.com
> > Cc: users@subversion.tigris.org
> > Subject: Re: Default server based properties
> >
> > On Mon, Apr 6, 2009 at 06:08, dieter oberkofler
> > <do...@gmail.com> wrote:
> > > Hi,
> > > How would I force Subversion to set some default properties for
> > > all/some files on the server side?
> > > I would for example like to have all document files (either by
> > > extension or for a directory) created with the "needs-lock"
> > property.
> > > Thank you,
> >
> > Any "forcing" you do must be via a pre-commit hook which
> > rejects any commit not conforming to your requirements.
> 
> ------------------------------------------------------
>
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageI
d=
> 1562269
> 
> To unsubscribe from this discussion, e-mail: [users-
> unsubscribe@subversion.tigris.org].

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1562296

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].


Re: Default server based properties

Posted by Andy Levy <an...@gmail.com>.
On Mon, Apr 6, 2009 at 10:49, Dieter Oberkofler
<do...@gmail.com> wrote:
> Understood, but is there any way to force setting preferences instead of
> just making sure that they are already set properly?

You can't "force" a client to do anything. The best you can do is
distribute a well-written config file to set auto-props on newly-added
files. But there's no guarantee that your users won't override or edit
those auto-props.

>> -----Original Message-----
>> From: Andy Levy [mailto:andy.levy@gmail.com]
>> Sent: Monday, April 06, 2009 2:18 PM
>> To: doberkofler.lists@gmail.com
>> Cc: users@subversion.tigris.org
>> Subject: Re: Default server based properties
>>
>> On Mon, Apr 6, 2009 at 06:08, dieter oberkofler
>> <do...@gmail.com> wrote:
>> > Hi,
>> > How would I force Subversion to set some default properties for
>> > all/some files on the server side?
>> > I would for example like to have all document files (either by
>> > extension or for a directory) created with the "needs-lock"
>> property.
>> > Thank you,
>>
>> Any "forcing" you do must be via a pre-commit hook which
>> rejects any commit not conforming to your requirements.
>
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1562275

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

RE: Efficient way to create a new branch from an existing working copy (SOLVED)

Posted by dieter oberkofler <do...@gmail.com>.
Excellent!
This is just what I was looking for.
Thank you,
Dieter 

> -----Original Message-----
> From: Johan Corveleyn [mailto:johan.corveleyn@uz.kuleuven.ac.be] 
> Sent: Thursday, July 02, 2009 09:43
> To: 'doberkofler.lists@gmail.com'; users@subversion.tigris.org
> Subject: RE: Efficient way to create a new branch from an 
> existing working copy
> 
> > The typical way how we create a new branch from a trunk is 
> by copying 
> > the trunk to a new branch on the server and then checkout the new 
> > branch to a local working copy.
> > As this is a very common procedure, I was wondering if this can 
> > eventually also be done in a more efficient/fast way.
> > Is there way to - instead of checking out the new working copy - 
> > physically duplicate the working copy and then somehow tell 
> Subversion 
> > to take this new directory as the working copy on the server?
> 
> I think you're looking for "svn switch":
> -------
> $ svn help switch
> switch (sw): Update the working copy to a different URL.
> usage: 1. switch URL[@PEGREV] [PATH]
>        2. switch --relocate FROM TO [PATH...]
> 
>   1. Update the working copy to mirror a new URL within the 
> repository.
>      This behavior is similar to 'svn update', and is the way to
>      move a working copy to a branch or tag within the same 
> repository.
>      If specified, PEGREV determines in which revision the 
> target is first
>      looked up.
> ...
> -------
> 
> So, suppose /path/to/wc-from-trunk is your trunk working 
> copy, you might try the following scenario:
> $ svn copy <url>/trunk <url>/branches/my-branch $ cp -r 
> /path/to/wc-from-trunk /path/to/wc-my-branch $ svn switch 
> <url>/branches/my-branch /path/to/wc-my-branch
> 
> Just be careful with local modifications or unversioned files 
> that you still had laying around in your trunk WC (they will 
> be copied to your new branch WC, so you'd carry them with 
> you). Keep an eye on the output of the svn switch command to 
> see if everything goes smoothly ...
> 
> Regards,
> Johan

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2367269

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

RE: Efficient way to create a new branch from an existing working copy

Posted by Johan Corveleyn <jo...@uz.kuleuven.ac.be>.
> The typical way how we create a new branch from a trunk is by
> copying the
> trunk to a new branch on the server and then checkout the new
> branch to a
> local working copy.
> As this is a very common procedure, I was wondering if this can
> eventually
> also be done in a more efficient/fast way.
> Is there way to - instead of checking out the new working copy -
> physically
> duplicate the working copy and then somehow tell Subversion to take
> this new
> directory as the working copy on the server?

I think you're looking for "svn switch":
-------
$ svn help switch
switch (sw): Update the working copy to a different URL.
usage: 1. switch URL[@PEGREV] [PATH]
       2. switch --relocate FROM TO [PATH...]

  1. Update the working copy to mirror a new URL within the repository.
     This behavior is similar to 'svn update', and is the way to
     move a working copy to a branch or tag within the same repository.
     If specified, PEGREV determines in which revision the target is first
     looked up.
...
-------

So, suppose /path/to/wc-from-trunk is your trunk working copy, you might try the following scenario:
$ svn copy <url>/trunk <url>/branches/my-branch
$ cp -r /path/to/wc-from-trunk /path/to/wc-my-branch
$ svn switch <url>/branches/my-branch /path/to/wc-my-branch

Just be careful with local modifications or unversioned files that you still had laying around in your trunk WC (they will be copied to your new branch WC, so you'd carry them with you). Keep an eye on the output of the svn switch command to see if everything goes smoothly ...

Regards,
Johan

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2367268

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].


Efficient way to create a new branch from an existing working copy

Posted by dieter oberkofler <do...@gmail.com>.
The typical way how we create a new branch from a trunk is by copying the
trunk to a new branch on the server and then checkout the new branch to a
local working copy.
As this is a very common procedure, I was wondering if this can eventually
also be done in a more efficient/fast way.
Is there way to - instead of checking out the new working copy - physically
duplicate the working copy and then somehow tell Subversion to take this new
directory as the working copy on the server?
Thank you,
Dieter

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2367263

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

RE: Default server based properties

Posted by Giulio T <gi...@uk.linedata.com>.
> Understood, but is there any way to force setting preferences
> instead of just making sure that they are already set properly?
> Thank you,
> D

I know it's not recommended but I do enforce the EOL.

The post commit hook check whether the committed files have the svn:eol-style property set. If it is not set or it is set to something else than LF, the post commit hooks use a WC on the server to set or change the property and then commits.

I know the user's WC becomes immediately out-of-date, but since it's just a property value I find it acceptable.

Giulio


Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851    VAT Reg No 778499447

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1562311

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].


RE: Default server based properties

Posted by dieter oberkofler <do...@gmail.com>.
Understood, but is there any way to force setting preferences instead of
just making sure that they are already set properly?
Thank you,
D 

> -----Original Message-----
> From: Andy Levy [mailto:andy.levy@gmail.com] 
> Sent: Monday, April 06, 2009 2:18 PM
> To: doberkofler.lists@gmail.com
> Cc: users@subversion.tigris.org
> Subject: Re: Default server based properties
> 
> On Mon, Apr 6, 2009 at 06:08, dieter oberkofler 
> <do...@gmail.com> wrote:
> > Hi,
> > How would I force Subversion to set some default properties for 
> > all/some files on the server side?
> > I would for example like to have all document files (either by 
> > extension or for a directory) created with the "needs-lock" 
> property.
> > Thank you,
> 
> Any "forcing" you do must be via a pre-commit hook which 
> rejects any commit not conforming to your requirements.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1562269

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: Default server based properties

Posted by Andy Levy <an...@gmail.com>.
On Mon, Apr 6, 2009 at 06:08, dieter oberkofler
<do...@gmail.com> wrote:
> Hi,
> How would I force Subversion to set some default properties for all/some
> files on the server side?
> I would for example like to have all document files (either by extension or
> for a directory) created with the "needs-lock" property.
> Thank you,

Any "forcing" you do must be via a pre-commit hook which rejects any
commit not conforming to your requirements.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1561072

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].