You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Blair Zajac <bl...@orcaware.com> on 2007/10/23 15:40:57 UTC
Rejecting commits to a 1.5 server from clients < 1.5
As somebody who runs an svn server for open source code and one for
internal corporate use, I want to ensure that all svn clients that
commit send merge info to the server and I don't want to loose this
information. So I want to require that all clients that commit are
at least Subversion 1.5 or later. I can imagine that lots of
corporate shops will want this requirement to prevent somebody from
using some random svn client that does not supply merge info and
makes life harder for a release manager.
Are we planning on offering such a capability? If so, how are we
doing this? If not, this seems like a good use for the start-commit
script to supply an additional parameter, say an $OPTIONS, that can
be parsed for the support the client offers.
Blair
--
Blair Zajac, Ph.D.
<bl...@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Blair Zajac <bl...@orcaware.com>.
Justin Erenkrantz wrote:
> On Oct 23, 2007 1:21 PM, Blair Zajac <bl...@orcaware.com> wrote:
>> I'm not looking for a 100% reliability. As long as somebody downloads a well
>> known binary, say Subclipse, our .exe's or TortoiseSVN who will do a good build,
>> or downloads and compiles from source and doesn't modify the source, that's good
>> enough for me.
>
> For WebDAV installs, you can do a BrowserMatch to reject non 1.5 user
> agent strings. Both ra_dav and ra_neon include the SVN/<version
> number> in the User-Agent headers. This is the simplest and
> most-straightforward way to block WebDAV accesses.
>
> So, really, you only need to do something for ra_svn... -- justin
Ahh, great idea.
Thanks,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Stefan Küng <to...@gmail.com>.
Daniel L. Rall wrote:
> On Wed, 24 Oct 2007, Stefan Küng wrote:
>
>> Justin Erenkrantz wrote:
>>> On Oct 23, 2007 1:21 PM, Blair Zajac <bl...@orcaware.com> wrote:
>>>> I'm not looking for a 100% reliability. As long as somebody downloads a
>>>> well
>>>> known binary, say Subclipse, our .exe's or TortoiseSVN who will do a good
>>>> build,
>>>> or downloads and compiles from source and doesn't modify the source,
>>>> that's good
>>>> enough for me.
>>> For WebDAV installs, you can do a BrowserMatch to reject non 1.5 user
>>> agent strings. Both ra_dav and ra_neon include the SVN/<version
>>> number> in the User-Agent headers. This is the simplest and
>>> most-straightforward way to block WebDAV accesses.
>>>
>>> So, really, you only need to do something for ra_svn... -- justin
>> If I may request one tiny additional feature for the agent strings:
>> currently, the agent string is a fixed #define deep inside the svn
>> library. I'd like to customize that one to include some client specific
>> stuff. Something like
>>
>> #ifdef CUSTOM_CLIENT_AGENT_STRING
>> #define SVN_FULL_AGENT_STRING CUSTOM_CLIENT_AGENT_STRING + SVN_AGENT_STRING
>> #else
>> #define SVN_FULL_AGENT_STRING SVN_AGENT_STRING
>> #endif
>>
>> that way, svn clients can add their own string, and hosters could create
>> some statistics about the use of svn clients. Kind of like the browser
>> statistics for websites.
>
> I'm in favor of something along these lines, since canonical User-Agent
> identifiers are retained, but the User-Agent is still allowed to be
> extended.
>
> Stefan, do you have an example of how this would look to the server, in
> the HTTP headers?
I think it would look as it does now, just with a custom string prepended?
I guess we could do it the same way browsers do it:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Instead of "Mozilla/4.0", put the client name there, and inside the
brackets the library and version of the library against which the client
is linked.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Stefan Küng <to...@gmail.com>.
Justin Erenkrantz wrote:
> On Oct 23, 2007 1:21 PM, Blair Zajac <bl...@orcaware.com> wrote:
>> I'm not looking for a 100% reliability. As long as somebody downloads a well
>> known binary, say Subclipse, our .exe's or TortoiseSVN who will do a good build,
>> or downloads and compiles from source and doesn't modify the source, that's good
>> enough for me.
>
> For WebDAV installs, you can do a BrowserMatch to reject non 1.5 user
> agent strings. Both ra_dav and ra_neon include the SVN/<version
> number> in the User-Agent headers. This is the simplest and
> most-straightforward way to block WebDAV accesses.
>
> So, really, you only need to do something for ra_svn... -- justin
If I may request one tiny additional feature for the agent strings:
currently, the agent string is a fixed #define deep inside the svn
library. I'd like to customize that one to include some client specific
stuff. Something like
#ifdef CUSTOM_CLIENT_AGENT_STRING
#define SVN_FULL_AGENT_STRING CUSTOM_CLIENT_AGENT_STRING + SVN_AGENT_STRING
#else
#define SVN_FULL_AGENT_STRING SVN_AGENT_STRING
#endif
that way, svn clients can add their own string, and hosters could create
some statistics about the use of svn clients. Kind of like the browser
statistics for websites.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Oct 23, 2007 1:21 PM, Blair Zajac <bl...@orcaware.com> wrote:
> I'm not looking for a 100% reliability. As long as somebody downloads a well
> known binary, say Subclipse, our .exe's or TortoiseSVN who will do a good build,
> or downloads and compiles from source and doesn't modify the source, that's good
> enough for me.
For WebDAV installs, you can do a BrowserMatch to reject non 1.5 user
agent strings. Both ra_dav and ra_neon include the SVN/<version
number> in the User-Agent headers. This is the simplest and
most-straightforward way to block WebDAV accesses.
So, really, you only need to do something for ra_svn... -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Daniel Rall <dl...@collab.net>.
On Tue, 23 Oct 2007, Blair Zajac wrote:
> Mark Phippard wrote:
...
> >If we advertise a way to block clients based on version, and people
> >can get around it, some people will accept this and others will see it
> >as a problem. I think Dan is just saying if we add something like
> >this we probably need to be careful in how we describe it to make it
> >clear.
>
> OK. But one way to get people to see it as a problem is to put the word
> security in there. It's not really a security issue any way, as least in
> my mind, it's more of a data completeness issue, after all, we're not
> stopping people from using 1.4 clients against a 1.5 server.
Sure. But to your typical user, this is just splitting hairs. :-\
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Blair Zajac <bl...@orcaware.com>.
Mark Phippard wrote:
>>> We need to be very clear that we're _not doing access control_ here,
>>> so those looking for guaranteed protection from malicious users
>>> shouldn't rely on this facility for it. What we're doing is providing
>>> a nicety that'll keep 99% of the user base from shooting themselves in
>>> the foot, regardless of the fact that we're providing no real
>>> security.
>> Good point. But I wasn't even really thinking about this in a security context,
>> just a capability context. Do we want to conflate the two?
>>
>> Also, should we open a ticket with a 1.5 milestone for this?
>
> If we advertise a way to block clients based on version, and people
> can get around it, some people will accept this and others will see it
> as a problem. I think Dan is just saying if we add something like
> this we probably need to be careful in how we describe it to make it
> clear.
OK. But one way to get people to see it as a problem is to put the word
security in there. It's not really a security issue any way, as least in my
mind, it's more of a data completeness issue, after all, we're not stopping
people from using 1.4 clients against a 1.5 server.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Mark Phippard <ma...@gmail.com>.
On 10/23/07, Blair Zajac <bl...@orcaware.com> wrote:
> Daniel Rall wrote:
> > On Tue, 23 Oct 2007, Blair Zajac wrote:
> >
> >> Daniel Rall wrote:
> >>> On Tue, 23 Oct 2007, C. Michael Pilato wrote:
> >>>
> >>>> Blair Zajac wrote:
> >>>>> As somebody who runs an svn server for open source code and one for
> >>>>> internal corporate use, I want to ensure that all svn clients that
> >>>>> commit send merge info to the server and I don't want to loose this
> >>>>> information. So I want to require that all clients that commit are at
> >>>>> least Subversion 1.5 or later. I can imagine that lots of corporate
> >>>>> shops will want this requirement to prevent somebody from using some
> >>>>> random svn client that does not supply merge info and makes life harder
> >>>>> for a release manager.
> >>>>>
> >>>>> Are we planning on offering such a capability? If so, how are we doing
> >>>>> this? If not, this seems like a good use for the start-commit script to
> >>>>> supply an additional parameter, say an $OPTIONS, that can be parsed for
> >>>>> the support the client offers.
> >>>> This was brought up to me personally at SubConf last week as a fairly
> >>>> serious issue in corporate environments. It was the first I could recall
> >>>> of
> >>>> hearing such a concern, but here you are echoing it. So, while I don't
> >>>> yet
> >>>> have a strong position on the matter technically, I do believe we need to
> >>>> have this discussion, and now's as good a time as any to do so.
> >>> Blair actually brought this issue up about a year ago, and the
> >>> consensus was that while it's certainly a valid issue, we currently
> >>> have no reliable way to do this. We simply can't trust the client, so
> >>> can't enforce this with 100% reliability. We can, however, put some
> >>> "guideline" constraints in place (along the lines of the suggestions
> >>> in this thread).
> >> I'm not looking for a 100% reliability. As long as somebody downloads a
> >> well known binary, say Subclipse, our .exe's or TortoiseSVN who will do a
> >> good build, or downloads and compiles from source and doesn't modify the
> >> source, that's good enough for me.
> >>
> >> If somebody wants to take a 1.4 client and have it tell the server it will
> >> send mergeinfo over when it really won't, I'm ok with that. I'm not
> >> looking to solve that problem.
> >
> > Yup, I didn't think you were. It's not the well-informed user base
> > that I'm concerned about. :-)
> >
> >> I'm assuming this is the issue you're talking about?
> >>
> >> What do you mean by guildline constraints? Anything less then a
> >> notification of the client's capabilities to the server won't be sufficient.
> >
> > Mark and I had a little over-the-cube-wall discussion about this. To
> > be painfully clear: I am in favor of this capability announcement!
>
> Ahh, great.
>
> >
> > The point I was trying to make is about how we advertise this
> > behavior.
> >
> > We need to be very clear that we're _not doing access control_ here,
> > so those looking for guaranteed protection from malicious users
> > shouldn't rely on this facility for it. What we're doing is providing
> > a nicety that'll keep 99% of the user base from shooting themselves in
> > the foot, regardless of the fact that we're providing no real
> > security.
>
> Good point. But I wasn't even really thinking about this in a security context,
> just a capability context. Do we want to conflate the two?
>
> Also, should we open a ticket with a 1.5 milestone for this?
If we advertise a way to block clients based on version, and people
can get around it, some people will accept this and others will see it
as a problem. I think Dan is just saying if we add something like
this we probably need to be careful in how we describe it to make it
clear.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Blair Zajac <bl...@orcaware.com>.
Daniel Rall wrote:
> On Tue, 23 Oct 2007, Blair Zajac wrote:
>
>> Daniel Rall wrote:
> ...
>>> The point I was trying to make is about how we advertise this
>>> behavior.
>>>
>>> We need to be very clear that we're _not doing access control_ here,
>>> so those looking for guaranteed protection from malicious users
>>> shouldn't rely on this facility for it. What we're doing is providing
>>> a nicety that'll keep 99% of the user base from shooting themselves in
>>> the foot, regardless of the fact that we're providing no real
>>> security.
>> Good point. But I wasn't even really thinking about this in a security
>> context, just a capability context. Do we want to conflate the two?
>
> I don't want to. But, in this particular case, it's easy for users to
> make that mistake.
>
>> Also, should we open a ticket with a 1.5 milestone for this?
>
> It'd certainly be far less valuable to put this into a 1.5.x point
> release, where x > 0. But, we're not making much progress towards
> converging the issue trend towards zero...
<glass half full>
Well, I don't know. I just looked and there's 16 open tickets for 1.5, out of a
total of 174 tickets with the 1.5 milestone, so that looks pretty good, only
~10% left.
</glass half full>
Most are with merge tracking, so I guess that'll take a bit longer. This work
could definitely be done concurrently.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Daniel Rall <dl...@collab.net>.
On Tue, 23 Oct 2007, Blair Zajac wrote:
> Daniel Rall wrote:
...
> >The point I was trying to make is about how we advertise this
> >behavior.
> >
> >We need to be very clear that we're _not doing access control_ here,
> >so those looking for guaranteed protection from malicious users
> >shouldn't rely on this facility for it. What we're doing is providing
> >a nicety that'll keep 99% of the user base from shooting themselves in
> >the foot, regardless of the fact that we're providing no real
> >security.
>
> Good point. But I wasn't even really thinking about this in a security
> context, just a capability context. Do we want to conflate the two?
I don't want to. But, in this particular case, it's easy for users to
make that mistake.
> Also, should we open a ticket with a 1.5 milestone for this?
It'd certainly be far less valuable to put this into a 1.5.x point
release, where x > 0. But, we're not making much progress towards
converging the issue trend towards zero...
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Blair Zajac <bl...@orcaware.com>.
Daniel Rall wrote:
> On Tue, 23 Oct 2007, Blair Zajac wrote:
>
>> Daniel Rall wrote:
>>> On Tue, 23 Oct 2007, C. Michael Pilato wrote:
>>>
>>>> Blair Zajac wrote:
>>>>> As somebody who runs an svn server for open source code and one for
>>>>> internal corporate use, I want to ensure that all svn clients that
>>>>> commit send merge info to the server and I don't want to loose this
>>>>> information. So I want to require that all clients that commit are at
>>>>> least Subversion 1.5 or later. I can imagine that lots of corporate
>>>>> shops will want this requirement to prevent somebody from using some
>>>>> random svn client that does not supply merge info and makes life harder
>>>>> for a release manager.
>>>>>
>>>>> Are we planning on offering such a capability? If so, how are we doing
>>>>> this? If not, this seems like a good use for the start-commit script to
>>>>> supply an additional parameter, say an $OPTIONS, that can be parsed for
>>>>> the support the client offers.
>>>> This was brought up to me personally at SubConf last week as a fairly
>>>> serious issue in corporate environments. It was the first I could recall
>>>> of
>>>> hearing such a concern, but here you are echoing it. So, while I don't
>>>> yet
>>>> have a strong position on the matter technically, I do believe we need to
>>>> have this discussion, and now's as good a time as any to do so.
>>> Blair actually brought this issue up about a year ago, and the
>>> consensus was that while it's certainly a valid issue, we currently
>>> have no reliable way to do this. We simply can't trust the client, so
>>> can't enforce this with 100% reliability. We can, however, put some
>>> "guideline" constraints in place (along the lines of the suggestions
>>> in this thread).
>> I'm not looking for a 100% reliability. As long as somebody downloads a
>> well known binary, say Subclipse, our .exe's or TortoiseSVN who will do a
>> good build, or downloads and compiles from source and doesn't modify the
>> source, that's good enough for me.
>>
>> If somebody wants to take a 1.4 client and have it tell the server it will
>> send mergeinfo over when it really won't, I'm ok with that. I'm not
>> looking to solve that problem.
>
> Yup, I didn't think you were. It's not the well-informed user base
> that I'm concerned about. :-)
>
>> I'm assuming this is the issue you're talking about?
>>
>> What do you mean by guildline constraints? Anything less then a
>> notification of the client's capabilities to the server won't be sufficient.
>
> Mark and I had a little over-the-cube-wall discussion about this. To
> be painfully clear: I am in favor of this capability announcement!
Ahh, great.
>
> The point I was trying to make is about how we advertise this
> behavior.
>
> We need to be very clear that we're _not doing access control_ here,
> so those looking for guaranteed protection from malicious users
> shouldn't rely on this facility for it. What we're doing is providing
> a nicety that'll keep 99% of the user base from shooting themselves in
> the foot, regardless of the fact that we're providing no real
> security.
Good point. But I wasn't even really thinking about this in a security context,
just a capability context. Do we want to conflate the two?
Also, should we open a ticket with a 1.5 milestone for this?
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Daniel Rall <dl...@collab.net>.
On Tue, 23 Oct 2007, Blair Zajac wrote:
> Daniel Rall wrote:
> >On Tue, 23 Oct 2007, C. Michael Pilato wrote:
> >
> >>Blair Zajac wrote:
> >>>As somebody who runs an svn server for open source code and one for
> >>>internal corporate use, I want to ensure that all svn clients that
> >>>commit send merge info to the server and I don't want to loose this
> >>>information. So I want to require that all clients that commit are at
> >>>least Subversion 1.5 or later. I can imagine that lots of corporate
> >>>shops will want this requirement to prevent somebody from using some
> >>>random svn client that does not supply merge info and makes life harder
> >>>for a release manager.
> >>>
> >>>Are we planning on offering such a capability? If so, how are we doing
> >>>this? If not, this seems like a good use for the start-commit script to
> >>>supply an additional parameter, say an $OPTIONS, that can be parsed for
> >>>the support the client offers.
> >>This was brought up to me personally at SubConf last week as a fairly
> >>serious issue in corporate environments. It was the first I could recall
> >>of
> >>hearing such a concern, but here you are echoing it. So, while I don't
> >>yet
> >>have a strong position on the matter technically, I do believe we need to
> >>have this discussion, and now's as good a time as any to do so.
> >
> >Blair actually brought this issue up about a year ago, and the
> >consensus was that while it's certainly a valid issue, we currently
> >have no reliable way to do this. We simply can't trust the client, so
> >can't enforce this with 100% reliability. We can, however, put some
> >"guideline" constraints in place (along the lines of the suggestions
> >in this thread).
>
> I'm not looking for a 100% reliability. As long as somebody downloads a
> well known binary, say Subclipse, our .exe's or TortoiseSVN who will do a
> good build, or downloads and compiles from source and doesn't modify the
> source, that's good enough for me.
>
> If somebody wants to take a 1.4 client and have it tell the server it will
> send mergeinfo over when it really won't, I'm ok with that. I'm not
> looking to solve that problem.
Yup, I didn't think you were. It's not the well-informed user base
that I'm concerned about. :-)
> I'm assuming this is the issue you're talking about?
>
> What do you mean by guildline constraints? Anything less then a
> notification of the client's capabilities to the server won't be sufficient.
Mark and I had a little over-the-cube-wall discussion about this. To
be painfully clear: I am in favor of this capability announcement!
The point I was trying to make is about how we advertise this
behavior.
We need to be very clear that we're _not doing access control_ here,
so those looking for guaranteed protection from malicious users
shouldn't rely on this facility for it. What we're doing is providing
a nicety that'll keep 99% of the user base from shooting themselves in
the foot, regardless of the fact that we're providing no real
security.
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Jack Repenning <jr...@collab.net>.
On Oct 24, 2007, at 9:31 PM, Lars Gullik Bjønnes wrote:
> This is probably something I have not understood clearly yet: with a
> 1.5 client will mergeinfo always be sent, even if you run without
> '-g'?
>
> If not, is it enough to enforce 1.5 client? Must I not also be able to
> enforce '-g'?
(Note that, in the current state of trunk/, things have been
reversed: there's no "-g" at all for merge, but rather you have to
specify "--ignore-ancestry" to turn "-g-like" behavior off. But your
question remains, of course.)
No, we don't have to militate that all users user the merge info.
The option is there for 1.5 clients.
You might wonder why we're so up-in-arms about preventing 1.4 clients
from leaving this info out, if we're willing to let 1.5 clients do it
by choice. The answer is that they do have the choice, and if they
take it, then they're accepting responsibility for the consequences.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Lars Gullik Bjønnes <la...@gullik.net>.
Blair Zajac <bl...@orcaware.com> writes:
[...]
| If somebody wants to take a 1.4 client and have it tell the server it
| will send mergeinfo over when it really won't, I'm ok with that. I'm
| not looking to solve that problem.
This is probably something I have not understood clearly yet: with a
1.5 client will mergeinfo always be sent, even if you run without
'-g'?
If not, is it enough to enforce 1.5 client? Must I not also be able to
enforce '-g'?
--
Lgb
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by da...@aciworldwide.com.
Blair Zajac <bl...@orcaware.com> wrote on 24/10/2007 06:21:56 AM:
> Daniel Rall wrote:
<snip>
> >
> > Blair actually brought this issue up about a year ago, and the
> > consensus was that while it's certainly a valid issue, we currently
> > have no reliable way to do this. We simply can't trust the client, so
> > can't enforce this with 100% reliability. We can, however, put some
> > "guideline" constraints in place (along the lines of the suggestions
> > in this thread).
>
> I'm not looking for a 100% reliability. As long as somebody downloads a
well
> known binary, say Subclipse, our .exe's or TortoiseSVN who will do a
> good build,
> or downloads and compiles from source and doesn't modify the source,
> that's good
> enough for me.
+1
Dave
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Blair Zajac <bl...@orcaware.com>.
Daniel Rall wrote:
> On Tue, 23 Oct 2007, C. Michael Pilato wrote:
>
>> Blair Zajac wrote:
>>> As somebody who runs an svn server for open source code and one for
>>> internal corporate use, I want to ensure that all svn clients that
>>> commit send merge info to the server and I don't want to loose this
>>> information. So I want to require that all clients that commit are at
>>> least Subversion 1.5 or later. I can imagine that lots of corporate
>>> shops will want this requirement to prevent somebody from using some
>>> random svn client that does not supply merge info and makes life harder
>>> for a release manager.
>>>
>>> Are we planning on offering such a capability? If so, how are we doing
>>> this? If not, this seems like a good use for the start-commit script to
>>> supply an additional parameter, say an $OPTIONS, that can be parsed for
>>> the support the client offers.
>> This was brought up to me personally at SubConf last week as a fairly
>> serious issue in corporate environments. It was the first I could recall of
>> hearing such a concern, but here you are echoing it. So, while I don't yet
>> have a strong position on the matter technically, I do believe we need to
>> have this discussion, and now's as good a time as any to do so.
>
> Blair actually brought this issue up about a year ago, and the
> consensus was that while it's certainly a valid issue, we currently
> have no reliable way to do this. We simply can't trust the client, so
> can't enforce this with 100% reliability. We can, however, put some
> "guideline" constraints in place (along the lines of the suggestions
> in this thread).
I'm not looking for a 100% reliability. As long as somebody downloads a well
known binary, say Subclipse, our .exe's or TortoiseSVN who will do a good build,
or downloads and compiles from source and doesn't modify the source, that's good
enough for me.
If somebody wants to take a 1.4 client and have it tell the server it will send
mergeinfo over when it really won't, I'm ok with that. I'm not looking to solve
that problem.
I'm assuming this is the issue you're talking about?
What do you mean by guildline constraints? Anything less then a notification of
the client's capabilities to the server won't be sufficient.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Daniel Rall <dl...@collab.net>.
On Tue, 23 Oct 2007, C. Michael Pilato wrote:
> Blair Zajac wrote:
> > As somebody who runs an svn server for open source code and one for
> > internal corporate use, I want to ensure that all svn clients that
> > commit send merge info to the server and I don't want to loose this
> > information. So I want to require that all clients that commit are at
> > least Subversion 1.5 or later. I can imagine that lots of corporate
> > shops will want this requirement to prevent somebody from using some
> > random svn client that does not supply merge info and makes life harder
> > for a release manager.
> >
> > Are we planning on offering such a capability? If so, how are we doing
> > this? If not, this seems like a good use for the start-commit script to
> > supply an additional parameter, say an $OPTIONS, that can be parsed for
> > the support the client offers.
>
> This was brought up to me personally at SubConf last week as a fairly
> serious issue in corporate environments. It was the first I could recall of
> hearing such a concern, but here you are echoing it. So, while I don't yet
> have a strong position on the matter technically, I do believe we need to
> have this discussion, and now's as good a time as any to do so.
Blair actually brought this issue up about a year ago, and the
consensus was that while it's certainly a valid issue, we currently
have no reliable way to do this. We simply can't trust the client, so
can't enforce this with 100% reliability. We can, however, put some
"guideline" constraints in place (along the lines of the suggestions
in this thread).
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by David Glasser <gl...@davidglasser.net>.
On 10/23/07, Mark Phippard <ma...@gmail.com> wrote:
> On 10/23/07, Daniel Rall <dl...@collab.net> wrote:
> > On Tue, 23 Oct 2007, Jack Repenning wrote:
> >
> > > On Oct 23, 2007, at 11:17 PM, Blair Zajac wrote:
> > >
> > > >How are we going to do this for ra_svn?
> > >
> > > And what about ra_local? Do we assume that anyone with a local repo
> > > is smart enough to worry about their own versionitis?
> >
> > A pre-1.5 client cannot read a 1.5 repository (due to a repos format
> > number bump), so this is actually the safest case for us, and already
> > (de-facto) enforced.
>
> Isn't this only true if the repository is created with 1.5? I thought
> the bump was tied to the sharding. I thought Merge Tracking just
> silently added a SQLite DB and did not bump the format.
You are correct.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Daniel Rall <dl...@collab.net>.
On Tue, 23 Oct 2007, Mark Phippard wrote:
> On 10/23/07, Daniel Rall <dl...@collab.net> wrote:
> > On Tue, 23 Oct 2007, Jack Repenning wrote:
> >
> > > On Oct 23, 2007, at 11:17 PM, Blair Zajac wrote:
> > >
> > > >How are we going to do this for ra_svn?
> > >
> > > And what about ra_local? Do we assume that anyone with a local repo
> > > is smart enough to worry about their own versionitis?
> >
> > A pre-1.5 client cannot read a 1.5 repository (due to a repos format
> > number bump), so this is actually the safest case for us, and already
> > (de-facto) enforced.
>
> Isn't this only true if the repository is created with 1.5? I thought
> the bump was tied to the sharding. I thought Merge Tracking just
> silently added a SQLite DB and did not bump the format.
I don't recall -- I was just recounting experiences I ran into during
development, where I couldn't access a 1.5 repos with a pre-1.5
client. But, those cases were always new 1.5 repositories created for
testing, which means they were sharded FSFS repositories, which is in
line with what Mark says here.
Looking over the code base and history, I don't see a format bump
associated with the mergeinfo index. I think we were able to avoid a
format bump at that time, by simply automatically creating the index
if not already present.
So, if the FSFS and BDB backends will read pre-1.5 repositories
without automatically bumping their format (e.g. like libsvn_wc does
to the WC), we may not be protected from this case in all situations.
On a related note, I recall discussing making the
MERGE_INFO_INDEX_SCHEMA_FORMAT use the same format number as the FS.
Anyone recall why we didn't do so?
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Mark Phippard <ma...@gmail.com>.
On 10/23/07, Daniel Rall <dl...@collab.net> wrote:
> On Tue, 23 Oct 2007, Jack Repenning wrote:
>
> > On Oct 23, 2007, at 11:17 PM, Blair Zajac wrote:
> >
> > >How are we going to do this for ra_svn?
> >
> > And what about ra_local? Do we assume that anyone with a local repo
> > is smart enough to worry about their own versionitis?
>
> A pre-1.5 client cannot read a 1.5 repository (due to a repos format
> number bump), so this is actually the safest case for us, and already
> (de-facto) enforced.
Isn't this only true if the repository is created with 1.5? I thought
the bump was tied to the sharding. I thought Merge Tracking just
silently added a SQLite DB and did not bump the format.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Daniel Rall <dl...@collab.net>.
On Tue, 23 Oct 2007, Jack Repenning wrote:
> On Oct 23, 2007, at 11:17 PM, Blair Zajac wrote:
>
> >How are we going to do this for ra_svn?
>
> And what about ra_local? Do we assume that anyone with a local repo
> is smart enough to worry about their own versionitis?
A pre-1.5 client cannot read a 1.5 repository (due to a repos format
number bump), so this is actually the safest case for us, and already
(de-facto) enforced.
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Jack Repenning <jr...@collab.net>.
On Oct 23, 2007, at 11:17 PM, Blair Zajac wrote:
> How are we going to do this for ra_svn?
And what about ra_local? Do we assume that anyone with a local repo
is smart enough to worry about their own versionitis?
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by David Glasser <gl...@davidglasser.net>.
On 10/23/07, Blair Zajac <bl...@orcaware.com> wrote:
> C. Michael Pilato wrote:
> > Blair Zajac wrote:
> >> As somebody who runs an svn server for open source code and one for
> >> internal corporate use, I want to ensure that all svn clients that
> >> commit send merge info to the server and I don't want to loose this
> >> information. So I want to require that all clients that commit are at
> >> least Subversion 1.5 or later. I can imagine that lots of corporate
> >> shops will want this requirement to prevent somebody from using some
> >> random svn client that does not supply merge info and makes life harder
> >> for a release manager.
> >>
> >> Are we planning on offering such a capability? If so, how are we doing
> >> this? If not, this seems like a good use for the start-commit script to
> >> supply an additional parameter, say an $OPTIONS, that can be parsed for
> >> the support the client offers.
> >
> > This was brought up to me personally at SubConf last week as a fairly
> > serious issue in corporate environments. It was the first I could recall of
> > hearing such a concern, but here you are echoing it. So, while I don't yet
> > have a strong position on the matter technically, I do believe we need to
> > have this discussion, and now's as good a time as any to do so.
>
> I would guess that WebDAV going to be easy to do, just add another HTTP header,
> say X-Svn-Client-Support or something, that mod_dav_svn will parse and propogate
> to the hook scripts? We could have a semicolon separated list of strings, much
> like the HTTP Accept header.
>
> How are we going to do this for ra_svn?
That's even easier; ra_svn already supports both clients and servers
sending capabilities.
The part requiring design to me is where we put this preference (is it
per-repo? per-server? etc etc)
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Blair Zajac <bl...@orcaware.com>.
C. Michael Pilato wrote:
> Blair Zajac wrote:
>> As somebody who runs an svn server for open source code and one for
>> internal corporate use, I want to ensure that all svn clients that
>> commit send merge info to the server and I don't want to loose this
>> information. So I want to require that all clients that commit are at
>> least Subversion 1.5 or later. I can imagine that lots of corporate
>> shops will want this requirement to prevent somebody from using some
>> random svn client that does not supply merge info and makes life harder
>> for a release manager.
>>
>> Are we planning on offering such a capability? If so, how are we doing
>> this? If not, this seems like a good use for the start-commit script to
>> supply an additional parameter, say an $OPTIONS, that can be parsed for
>> the support the client offers.
>
> This was brought up to me personally at SubConf last week as a fairly
> serious issue in corporate environments. It was the first I could recall of
> hearing such a concern, but here you are echoing it. So, while I don't yet
> have a strong position on the matter technically, I do believe we need to
> have this discussion, and now's as good a time as any to do so.
I would guess that WebDAV going to be easy to do, just add another HTTP header,
say X-Svn-Client-Support or something, that mod_dav_svn will parse and propogate
to the hook scripts? We could have a semicolon separated list of strings, much
like the HTTP Accept header.
How are we going to do this for ra_svn?
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by "C. Michael Pilato" <cm...@collab.net>.
Blair Zajac wrote:
> As somebody who runs an svn server for open source code and one for
> internal corporate use, I want to ensure that all svn clients that
> commit send merge info to the server and I don't want to loose this
> information. So I want to require that all clients that commit are at
> least Subversion 1.5 or later. I can imagine that lots of corporate
> shops will want this requirement to prevent somebody from using some
> random svn client that does not supply merge info and makes life harder
> for a release manager.
>
> Are we planning on offering such a capability? If so, how are we doing
> this? If not, this seems like a good use for the start-commit script to
> supply an additional parameter, say an $OPTIONS, that can be parsed for
> the support the client offers.
This was brought up to me personally at SubConf last week as a fairly
serious issue in corporate environments. It was the first I could recall of
hearing such a concern, but here you are echoing it. So, while I don't yet
have a strong position on the matter technically, I do believe we need to
have this discussion, and now's as good a time as any to do so.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Blair Zajac <bl...@orcaware.com>.
Jack Repenning wrote:
> On Oct 23, 2007, at 9:41 PM, kmradke@rockwellcollins.com
> <ma...@rockwellcollins.com> wrote:
>
>>
>> Micah Elliott <mde@micahelliott.com <ma...@micahelliott.com>>
>> wrote on 10/23/2007 10:59:50 AM:
>>
>> > On 2007-10-23 Blair Zajac wrote:
>> >
>> > > As somebody who runs an svn server for open source code and one
>> > > for internal corporate use, I want to ensure that all svn
>> > > clients that commit send merge info to the server and I don't
>> > > want to loose this information. So I want to require that all
>> > > clients that commit are at least Subversion 1.5 or later.
>> > ...
>> > This will definitely a useful requirement for me (now that you
>> > thought of it :-). I'm also in a corporate setting with 100+
>> > committers. We're waiting to do our CVS conversion until 1.5
>> > since we'd hate to be without merge tracking.
>>
>> I'll do anything I can to stop our 1400+ users from shooting
>> themselves in the foot. (Because they hit my feet too!)
>
> This is interesting. I'm not raising an objection here, just exploring:
> if you have so strong a need to protect your users, don't you already
> have some other, more general means in place? Standard installations,
> "scorched-earth sysadmin," that sort of thing?
Even with the scorhed-earth systems, there are ways this could happen.
You could also have users who VPN in from home or a laptop that they set up for
themselves with the code and want to do commits.
Even with Eclipse and Subclipse, you don't need any root or admin privileges to
download and start to use it, you just need a system with Java installed on it.
So somebody could have an older 1.4 release and use commit with it.
I'm aware of corporations where you can have power users/developers who have
sudo or su privileges but aren't Subversion experts and may try a new Subversion
client that could be linked against 1.4.
There's always ways for somebody to grab some older svn client.
> The reason I ask: I've never worked in a shop that had such policies,
> but when I've talked to customers that do, they definitely want to
> control more than just the VC system. When Microsoft comes out with a
> new Word format, for example, they tend both to pre-install with the
> "write out in old format," and go around to existing machines and
> re-install, to lock that in. How does that spin with your situation? Do
> you not do that? Do you do that in general, but like the extra
> protection of server-side verification?
I think 'like' is too weak of a word. I don't count on the desktops being
installed or properly maintained, hence having the server do it is a requirement.
Also, the svn administrator may want a tight policy but the OS administrator's
don't have a scorched-earth policy, so don't properly maintain systems.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Stefan Küng <to...@gmail.com>.
Jack Repenning wrote:
> On Oct 23, 2007, at 9:41 PM, kmradke@rockwellcollins.com
> <ma...@rockwellcollins.com> wrote:
>
>>
>> Micah Elliott <mde@micahelliott.com <ma...@micahelliott.com>>
>> wrote on 10/23/2007 10:59:50 AM:
>>
>> > On 2007-10-23 Blair Zajac wrote:
>> >
>> > > As somebody who runs an svn server for open source code and one
>> > > for internal corporate use, I want to ensure that all svn
>> > > clients that commit send merge info to the server and I don't
>> > > want to loose this information. So I want to require that all
>> > > clients that commit are at least Subversion 1.5 or later.
>> > ...
>> > This will definitely a useful requirement for me (now that you
>> > thought of it :-). I'm also in a corporate setting with 100+
>> > committers. We're waiting to do our CVS conversion until 1.5
>> > since we'd hate to be without merge tracking.
>>
>> I'll do anything I can to stop our 1400+ users from shooting
>> themselves in the foot. (Because they hit my feet too!)
>
> This is interesting. I'm not raising an objection here, just exploring:
> if you have so strong a need to protect your users, don't you already
> have some other, more general means in place? Standard installations,
> "scorched-earth sysadmin," that sort of thing?
That works only if all people accessing the repository are in the same
windows domain. But a lot of companies have hired contractors which work
from remote places, and there it's not possible to have such policies
enforced.
Also don't forget that a lot of companies have much less or even no
restrictions for developers because in place: most dev tools need Admin
rights to work properly (it's a shame, but it's true), which means those
restrictions wouldn't work anyway.
I brought this issue up before (in the thread "[PATCH] Re: log/bmale -g
and old servers") because we had such requests before (even before there
was a *real* reason): people even wanted to block specific svn clients
because they were found unstable when the company tested them.
From past discussions on the TSVN list, I know that missing such a
feature would be a big "No, No!" for many companies, which means they
rather won't update their servers than to have to deal with the possible
mess they could get into.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by km...@rockwellcollins.com.
Jack Repenning <jr...@collab.net> wrote on 10/23/2007 11:51:46 AM:
> On Oct 23, 2007, at 9:41 PM, kmradke@rockwellcollins.com wrote:
>
> Micah Elliott <md...@micahelliott.com> wrote on 10/23/2007 10:59:50 AM:
>
> > On 2007-10-23 Blair Zajac wrote:
> >
> > > As somebody who runs an svn server for open source code and one
> > > for internal corporate use, I want to ensure that all svn
> > > clients that commit send merge info to the server and I don't
> > > want to loose this information. So I want to require that all
> > > clients that commit are at least Subversion 1.5 or later.
> > ...
> > This will definitely a useful requirement for me (now that you
> > thought of it :-). I'm also in a corporate setting with 100+
> > committers. We're waiting to do our CVS conversion until 1.5
> > since we'd hate to be without merge tracking.
>
> I'll do anything I can to stop our 1400+ users from shooting
> themselves in the foot. (Because they hit my feet too!)
>
> This is interesting. I'm not raising an objection here, just
> exploring: if you have so strong a need to protect your users, don't
> you already have some other, more general means in place? Standard
> installations, "scorched-earth sysadmin," that sort of thing?
We are getting more and more "non-technical" users of Subversion here.
Things really need to work "out of the box", with little tweaking on
their part. A standard install can only go as far as the tools allow
them to be configured. For example, I would love repository side
auto-props. That way I can control settings based upon the 300+
repositories instead of the 1400+ separate client installs.
We have lots of cases where the same user may want different
settings for different projects. Forcing them to manually
reconfigure their client is both time consuming and error prone.
If the client could pull that info from the server, setting up
a new user is trivial.
The real need is to protect me from having 1400 users call me and
say "what did I do wrong?".
I can enforce separate policies by preventing actions in hook
scripts, but that usually just confuses the user.
> The reason I ask: I've never worked in a shop that had such
> policies, but when I've talked to customers that do, they definitely
> want to control more than just the VC system. When Microsoft comes
> out with a new Word format, for example, they tend both to pre-
> install with the "write out in old format," and go around to
> existing machines and re-install, to lock that in. How does that
> spin with your situation? Do you not do that? Do you do that in
> general, but like the extra protection of server-side verification?
I'm primarily supporting CM systems here. We have a whole separate
department that does the rest of the (non-engineering) IT work.
Due to certification requirements, we do lock down environments, and
typically they are unchanging after a certain amount of time. The
problems occur when an individual needs to work on multiple projects
with (potentially) incompatible tools. (Probably have to solve
this with something like VM images...)
Anyway, back to the original reason of this thread, if older clients can
mess
up newer repos, we need a way to protect the repo from this happening.
While I can try and control what clients are used, I'm not able to
control all users at all times in all places. (Nor do I really want to.)
A "minimum supported client version" property per repo would easily
solve this specific problem, but something more general would probably
serve us better in the future.
Kevin Radke
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Jack Repenning <jr...@collab.net>.
On Oct 23, 2007, at 9:41 PM, kmradke@rockwellcollins.com wrote:
>
> Micah Elliott <md...@micahelliott.com> wrote on 10/23/2007 10:59:50 AM:
>
> > On 2007-10-23 Blair Zajac wrote:
> >
> > > As somebody who runs an svn server for open source code and one
> > > for internal corporate use, I want to ensure that all svn
> > > clients that commit send merge info to the server and I don't
> > > want to loose this information. So I want to require that all
> > > clients that commit are at least Subversion 1.5 or later.
> > ...
> > This will definitely a useful requirement for me (now that you
> > thought of it :-). I'm also in a corporate setting with 100+
> > committers. We're waiting to do our CVS conversion until 1.5
> > since we'd hate to be without merge tracking.
>
> I'll do anything I can to stop our 1400+ users from shooting
> themselves in the foot. (Because they hit my feet too!)
This is interesting. I'm not raising an objection here, just
exploring: if you have so strong a need to protect your users, don't
you already have some other, more general means in place? Standard
installations, "scorched-earth sysadmin," that sort of thing?
The reason I ask: I've never worked in a shop that had such policies,
but when I've talked to customers that do, they definitely want to
control more than just the VC system. When Microsoft comes out with
a new Word format, for example, they tend both to pre-install with
the "write out in old format," and go around to existing machines and
re-install, to lock that in. How does that spin with your situation?
Do you not do that? Do you do that in general, but like the extra
protection of server-side verification?
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by km...@rockwellcollins.com.
Micah Elliott <md...@micahelliott.com> wrote on 10/23/2007 10:59:50 AM:
> On 2007-10-23 Blair Zajac wrote:
>
> > As somebody who runs an svn server for open source code and one
> > for internal corporate use, I want to ensure that all svn
> > clients that commit send merge info to the server and I don't
> > want to loose this information. So I want to require that all
> > clients that commit are at least Subversion 1.5 or later.
>
> +1
+1
> > I can imagine that lots of corporate shops will want this
> > requirement to prevent somebody from using some random svn
> > client that does not supply merge info and makes life harder
> > for a release manager.
>
> This will definitely a useful requirement for me (now that you
> thought of it :-). I'm also in a corporate setting with 100+
> committers. We're waiting to do our CVS conversion until 1.5
> since we'd hate to be without merge tracking.
I'll do anything I can to stop our 1400+ users from shooting
themselves in the foot. (Because they hit my feet too!)
Kevin Radke
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Micah Elliott <md...@micahelliott.com>.
On 2007-10-23 Blair Zajac wrote:
> As somebody who runs an svn server for open source code and one
> for internal corporate use, I want to ensure that all svn
> clients that commit send merge info to the server and I don't
> want to loose this information. So I want to require that all
> clients that commit are at least Subversion 1.5 or later.
+1
> I can imagine that lots of corporate shops will want this
> requirement to prevent somebody from using some random svn
> client that does not supply merge info and makes life harder
> for a release manager.
This will definitely a useful requirement for me (now that you
thought of it :-). I'm also in a corporate setting with 100+
committers. We're waiting to do our CVS conversion until 1.5
since we'd hate to be without merge tracking.
--
_ _ ___
|V|icah |- lliott
" " """
mde@MicahElliott.com <>< http://MicahElliott.com
PGP: 0x7C07CBF0 ICQ: 369060435 Linux/Ubuntu: 417195/12440
HackerKey: v4sw6YUPCJhw5ln5pr7OPck2ma9u8Lw3m5l6Ui2e7t3b8LDMOen6a3XsMRr5
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Mark Phippard wrote:
> On 10/26/07, Jack Repenning <jr...@collab.net> wrote:
>> On Oct 26, 2007, at 5:17 PM, Miha Vitorovic wrote:
>>
>>> IMO, it's not about contradiction, it's about giving the users a
>>> choice.
>>> They can mix the clients, or the server admins can choose to force the
>>> version. More choice ==> a good thing.
>> Do server admins get this choice? That would be better, I agree --
>> and that was the way the conceptual proposal was originally put. But
>> I think the implementation proposal that eventually developed does
>> not involve choice: all 1.5 repositories will always reject all
>> access from pre-1.5 clients.
>>
>> Did I miss something there?
>
> I must have missed an actual implementation proposal but it would
> completely violate our compatibility rules if we disallowed pre-1.5
> clients. Any 1.x client has to be able to talk to any 1.x server.
>
> My assumption is that our rules would allow an admin to decide to
> restrict this in their configuration if they wanted. But the base
> tool itself has to support a 1.x client talking to 1.5 server.
That was my impression, too.
-Hyrum
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Mark Phippard <ma...@gmail.com>.
On 10/26/07, Jack Repenning <jr...@collab.net> wrote:
> On Oct 26, 2007, at 5:17 PM, Miha Vitorovic wrote:
>
> > IMO, it's not about contradiction, it's about giving the users a
> > choice.
> > They can mix the clients, or the server admins can choose to force the
> > version. More choice ==> a good thing.
>
> Do server admins get this choice? That would be better, I agree --
> and that was the way the conceptual proposal was originally put. But
> I think the implementation proposal that eventually developed does
> not involve choice: all 1.5 repositories will always reject all
> access from pre-1.5 clients.
>
> Did I miss something there?
I must have missed an actual implementation proposal but it would
completely violate our compatibility rules if we disallowed pre-1.5
clients. Any 1.x client has to be able to talk to any 1.x server.
My assumption is that our rules would allow an admin to decide to
restrict this in their configuration if they wanted. But the base
tool itself has to support a 1.x client talking to 1.5 server.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Blair Zajac <bl...@orcaware.com>.
Jack Repenning wrote:
> On Oct 26, 2007, at 5:17 PM, Miha Vitorovic wrote:
>
>> IMO, it's not about contradiction, it's about giving the users a choice.
>> They can mix the clients, or the server admins can choose to force the
>> version. More choice ==> a good thing.
>
> Do server admins get this choice? That would be better, I agree -- and
> that was the way the conceptual proposal was originally put. But I
> think the implementation proposal that eventually developed does not
> involve choice: all 1.5 repositories will always reject all access from
> pre-1.5 clients.
>
> Did I miss something there?
My idea was that the repository would pass an additional argument to the
start-commit script, $OPTIONS, which would be a semicolon separated list of
client capabilities. The start-commit script could decide to reject the commit
if it didn't find the required capability.
By default, there is no start-commit script in a repository, so it would allow
all commits from any Subversion client.
Regards,
Blair
--
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<bl...@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Jack Repenning <jr...@collab.net>.
On Oct 26, 2007, at 5:17 PM, Miha Vitorovic wrote:
> IMO, it's not about contradiction, it's about giving the users a
> choice.
> They can mix the clients, or the server admins can choose to force the
> version. More choice ==> a good thing.
Do server admins get this choice? That would be better, I agree --
and that was the way the conceptual proposal was originally put. But
I think the implementation proposal that eventually developed does
not involve choice: all 1.5 repositories will always reject all
access from pre-1.5 clients.
Did I miss something there?
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Miha Vitorovic <mv...@nil.si>.
Jack Repenning <jr...@collab.net> wrote on 26.10.2007 13:07:18:
>
> It has just occurred to me that we spent a lot of time on this list
> deciding to allow mixing 1.4 and 1.5 clients within a single working
> copy (so users could mix clients on a single client box), but with
> this thread we've dashed clear to the opposite extreme: we now
> require *all* clients on every box on the planet to upgrade to 1.5
> before we can upgrade the server. These are not quite contradictory
> positions, in that you can still imagine a careful management of the
> environment that satisfies the constraints ... but both these
> discussions were all about doubts that the environment would be
> carefully managed, so that doesn't seem like a way out.
>
> Is this near-contradiction really desirable?
Jack,
IMO, it's not about contradiction, it's about giving the users a choice.
They can mix the clients, or the server admins can choose to force the
version. More choice ==> a good thing.
Br,
---
Miha Vitorovic
Inženir v tehničnem področju
Customer Support Engineer
NIL Data Communications, Tivolska cesta 48, 1000 Ljubljana, Slovenia
Phone +386 1 4746 500 Fax +386 1 4746 501 http://www.NIL.si
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rejecting commits to a 1.5 server from clients < 1.5
Posted by Jack Repenning <jr...@collab.net>.
On Oct 23, 2007, at 9:10 PM, Blair Zajac wrote:
> As somebody who runs an svn server for open source code and one for
> internal corporate use, I want to ensure that all svn clients that
> commit send merge info to the server and I don't want to loose this
> information. So I want to require that all clients that commit are
> at least Subversion 1.5 or later. I can imagine that lots of
> corporate shops will want this requirement to prevent somebody from
> using some random svn client that does not supply merge info and
> makes life harder for a release manager.
>
> Are we planning on offering such a capability? If so, how are we
> doing this? If not, this seems like a good use for the start-
> commit script to supply an additional parameter, say an $OPTIONS,
> that can be parsed for the support the client offers.
It has just occurred to me that we spent a lot of time on this list
deciding to allow mixing 1.4 and 1.5 clients within a single working
copy (so users could mix clients on a single client box), but with
this thread we've dashed clear to the opposite extreme: we now
require *all* clients on every box on the planet to upgrade to 1.5
before we can upgrade the server. These are not quite contradictory
positions, in that you can still imagine a careful management of the
environment that satisfies the constraints ... but both these
discussions were all about doubts that the environment would be
carefully managed, so that doesn't seem like a way out.
Is this near-contradiction really desirable?
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org