Quoting Peter Lundblad <peter@famlundblad.se>:
> [snip example]
> > Shouldn't that fail the commit then, like it does for
> outdated files? Or do > we need a working copy to get that error?
> >
>
> How would subversion know what revision you are basing your
> edit on when you don't have a working copy? Normally, when
> you commit a change, the client says to the server: Hey, I
> have revision 14 of this file. Take that file and do these
> modifications. If there is a newer revision in the
> repository, then the server knows to throw a conflict error.
>
> Regards,
> //Peter
I thought about that when I drove to work, unfortunately I was too late for
recalling my question :)
We like to have this feature as well, we want to use it to sort of lock a branch
in a visible way.
We're setting up a Subversion repository for our internal software library. All
internally developed software is at release time packaged and published to that
repository by developers. Developers can still add files to the release location
( documentation, db scripts etc. ), with the benefit that all their changes are
tracked in Subversion. Then the folder is locked by ops, which later know
exactly which version to put into production.
By setting a property on the release package folder, we have a visible way to
indicate that the folder is locked + with a hook script we can really limit
write access to that folder. To set that property, we now have to do a
non-recursive checkout of that folder.
In our scenario there is no concurrent setting + editing of properties and I'd
like to avoid the need to checkout a folder. The folder itself contains large
package files, so with a non-recursive checkout we get those along as well.
Can I implement the propset on an url function with the svn API? Is there any
chance that if I do that it is accepted to be included in the contrib or tools
area of subversion? My company is not really fond of installing non-official
tools on production servers.
Lieven.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 1 14:29:43 2006