Re: SVN

[Branko Čibej]

On 24.08.2011 18:14, Beatriz Giacobe wrote:
> Olá,
>
> Eu tenho o subversion instalao no debian lenny v5 + apache2 consigo
> acessar pelo browser,
>
> mas preciso que ele funcione no tortoisesvn windowns e não estou
> conseguindo segue o erro:
>
> Error: Can't connect to host '192.168.1.71': Nenhuma conexão pôde ser
> feita porque a  
> Error: máquina de destino as recusou ativamente. 
>
>
> Eu não sei se existe mais alguma configuração para que ele funcione
> com o tortoise tem como me ajudar???

This doesn't look like anything related to Subversion, it's probably a
more generic problem with your network configuration.

-- Brane

Re: RE: Proxy authentication with Negotiate uses wrong host

[1983-01-06]

> Betreff: RE: Proxy authentication with Negotiate uses wrong host

> On Wed, 2011-08-24 at 05:52 -0400, Bert Huijben wrote:
> > Then somebody added Kerberos support to neon, but the api wasn't
> > updated to allow different behavior for the specific implementations.
> 
> Kerberos via HTTP negotiate is also insecure when not used over HTTPS.
> In HTTP negotiate, the GSSAPI mechanism (Kerberos) isn't used to protect
> the data stream, only to authenticate.  So you still need a secure
> channel.
> 
> (Also, negotiate auth does no channel binding, which means Kerberos
> provides no additional protection against MITM attacks on the TLS
> channel.  That just means it's still important for the client to verify
> the server cert.  I've heard that Microsoft has some extensions to RFC
> 4559 to do channel binding, but I don't know any details and Neon almost
> certainly doesn't have any support for it.)

Greg,

Are you refering to sole Kerberos or are you just concerned about transport 
encryption? Your statement somewhat irritates me.
Given that the HTTP traffic cannot be securely wrapped into the GSS content and 
nor the SASL QOP can be set (like for LDAP), I would neglect that and still say 
TLS is not of your concern but of mine or the users in general.

Correct me if I am wrong.

Mike
-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!   
Jetzt informieren: http://www.gmx.net/de/go/freephone

Re: RE: Proxy authentication with Negotiate uses wrong host

[1983-01-06]

Bert,

> > -Original Message-
> > From: 1983-01...@gmx.net [mailto:1983-01...@gmx.net]
> > Sent: woensdag 24 augustus 2011 10:47
> > To: us...@subversion.apache.org
> > Subject: Re: Proxy authentication with Negotiate uses wrong host
> > 
> > > On Wed, Aug 24, 2011 at 09:25:49AM +0200, 1983-01...@gmx.net wrote:
> > > > I'll do but why is Negotiate auth activated in session.c if the
> target
> > > host is ssy only? This should be on the user to decide not subversion.
> > >
> > > I don't know who made this decision and why.
> > > Maybe svn blame on that file leads to more info?
> > 
> > I checked blame already. There was a rather long explanation but still
> no
> > argument to me.
> 
> The Subversion parts of this code were written when neon only supported
> NTLM via Negotiate. NTLM is known to be insecure when not used over https.

I am aware of that. That's why I want to use Kerberos in the first place.
 
> Then somebody added Kerberos support to neon, but the api wasn't updated
> to allow different behavior for the specific implementations.
> 
> As Stefan already noted: this discussion belongs on the neon mailinglist.
> Once neon supports the necessary hooks/apis to enable Negotiate for the
> secure protocols we can enable them in Subversion. 
> (Or maybe neon can just enable the safe protocols all the time?)

Are you suggesting to file another ticket for that?

I would file two:

1. Subversion passes wrong hostname to build the SPN. (Have neon debug output).
2. Allow user to use any auth on any http scheme. Transport security should be 
user's concern, not subversion's one.

Mike
-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!   
Jetzt informieren: http://www.gmx.net/de/go/freephone

SVN

[Beatriz Giacobe]

Olá,

Eu tenho o subversion instalao no debian lenny v5 + apache2 consigo acessar
pelo browser,

mas preciso que ele funcione no tortoisesvn windowns e não estou conseguindo
segue o erro:

Error: Can't connect to host '192.168.1.71': Nenhuma conexão pôde ser feita
porque a
Error: máquina de destino as recusou ativamente.


Eu não sei se existe mais alguma configuração para que ele funcione com o
tortoise tem como me ajudar???

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

[Mark Therieau]

Earlier in this discussion I saw link to the FAQ which recommends using a
"template" file and a manual copy to an unversioned file (an instance of the
template).  http://subversion.apache.org/faq.html#ignore-commit

I can see how that approach handles part of the
please-help-me-with-these-semi-custom-ide-project-files requests, but also
leaves some key facets up to a manual procedure, like: "you just checked out
a new working copy? don't forget to copy the template project file into the
real project file" and "hey: I just updated the template project file; time
for everyone to merge these changes into their real project files (or just
copy the template again, understanding you may get re-prompted for login
credentials, etc)"

On the other hand, the template/instance procedure neatly avoids the "oops,
I just committed my local changes back to the repository" problems, since
the instance file (the one that the IDE mucks around with) never gets
committed.

What if svn were to grow a feature that directly supported this
template/instance pattern?  Possibly as a svn:template property set on the
template file (and maybe the value of svn:template being name of the
instance file?).  When "svn checkout" creates the template file, it would
also copy the template file to the instance file.  When "svn update" or "svn
merge" applies changes to the template file, the same changes would be
applied to the instance file (of course this is where things get a bit
tricky).  Allowing local changes to exist in the instance file would, of
course, be essential, but the instance file would never be committed back to
the repository.

I'm sure there are a list of other tricky issues with this approach, but my
sense is that it may be closer to the mark than a single file that serves
two purposes.  Need to set something for your local working copy? -- changes
go into the instance file and don't worry: those changes won't be committed.
 Need to make changes that get committed back to the repository so that
other working copies can get them? -- those changes go into the template
file.

regards,
markt

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

[Daniel Shahaf]

Neels J Hofmeyr wrote on Wed, Aug 24, 2011 at 23:14:34 +0200:
> On 08/24/2011 05:10 PM, Mark Phippard wrote:
> > BTW, admins can also lock files in the repository to prevent accidental
> > commits of sensitive information.
> 
> That's a good point, actually.
> 
> If I want to add an intentional change, I steal the lock. Then lock it back
> (using a separate WC to lock the file for myself). The commit bails even
> before the modifications are sent over the wire. It's a central config.
> 

Another option: use a pre-commit hook instead of locks.  It does mean
the local changes will be sent to the server --- which may be a problem.
But then, you have the same problem with people (or admins) stealing the
locks...

> But: Say a template path is locked; the result is that everyone with a
> filled-in template now gets failing commits all the time. Now you need a
> convenience thing that excludes this locked file from commit locally.
> 
> This still requires specific action on every single checkout to block the
> exact right files. Users will be forced to do that, they can't run a plain
> 'svn commit' and succeed.
> 
> This would cover all the needs *except* that a new checkout should
> local-hold automatically without further user action.
> 
> (So we can add a prop for that, ok, and then we can use that prop and don't
> need to duplicate with a changelists based implementation)
> 
> ~Neels
> 

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

[Neels J Hofmeyr]

On 08/24/2011 05:10 PM, Mark Phippard wrote:
> BTW, admins can also lock files in the repository to prevent accidental
> commits of sensitive information.

That's a good point, actually.

If I want to add an intentional change, I steal the lock. Then lock it back
(using a separate WC to lock the file for myself). The commit bails even
before the modifications are sent over the wire. It's a central config.

But: Say a template path is locked; the result is that everyone with a
filled-in template now gets failing commits all the time. Now you need a
convenience thing that excludes this locked file from commit locally.

This still requires specific action on every single checkout to block the
exact right files. Users will be forced to do that, they can't run a plain
'svn commit' and succeed.

This would cover all the needs *except* that a new checkout should
local-hold automatically without further user action.

(So we can add a prop for that, ok, and then we can use that prop and don't
need to duplicate with a changelists based implementation)

~Neels



signature.asc
Description: OpenPGP digital signature

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

[Daniel Shahaf]

Neels J Hofmeyr wrote on Wed, Aug 24, 2011 at 22:04:11 +0200:
> On 08/24/2011 04:01 PM, Daniel Shahaf wrote:
> > Neels J Hofmeyr wrote on Wed, Aug 24, 2011 at 15:32:20 +0200:
> >> Changelists have been *designed* in the flipped-over wrong-way-round: they
> >> *include*, not exclude selected items. We'd have to implement this against
> >> its basic design. (Like using switch for externals, remember?)
> > 
> > Changelists were designed to group files.  What's fundamentally flawed in
> > 
> > % svn cl foo A/mu ./iota
> > % svn commit --depth=empty A/mu ./iota --except-cl=foo
> 
> Usually the code goes like "if there is a changelist, act on the node only
> when it is part of the changelist." ...well, it's just what I remember
> faintly, admittedly. Is that true?
> 

My recollection is that 'svn $subcommand foo --changelist bar' applies
to one of:

- the subset of descendants of that are in changelist 'bar';
- both to foo and to members of 'bar'

where some subcommands behave differently than others.

> If it isn't, there's nothing wrong with your command at all. In fact that
> would be quite nice.
> 
> But from the ignore-on-commit perspective, you still need to remember to
> supply it at commit time.
> You'd need to make the changelist always secretly self-acting, and thus the
> changelist must have a special name, as Hyrum kindly pointed out :)
> If I can instead create a simple property to achieve the same, I'm happier.
> 

We could decide that the special changelist is always applied, unless
a node has been explicitly named as a commit target.  It wouldn't even
require a revision of the API signature :-)

> And your command example doesn't give you the ability to propagate it
> globally without even coding a single additional line of code. (none except
> warning messages we may want to introduce.)
> 

True.  But you could add [auto-changelists] to ~/.subversion/config...

(which doesn't solve the 'global propagation' problem, but helps a little)

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

[Peter Samuelson]

[Stefan Sperling]
> However, the merge meisters I've met are usually more competent in
> using svn than the average developer in the same organisation.  Often
> they're even the local svn gurus. I would trust them to give special
> consideration for files with svn:hold.  If the merge meister cannot
> handle this it's possible to fall back to the template solution
> people are using now.

I do not have the faith in mergemeisters you do.  I think when you
merge to a file that is on hold,

1) If you have no local mods to this file, it should somehow be marked
   to be exempt from the hold until it is committed.  (A temporary file
   property, presumably.)

2) If you do have local mods, this should be treated similar to a
   textual conflict: that file can't be committed (and a recursive
   commit on the directory the file is in will also fail) until it is
   resolved manually in some way.  The manual resolution moves the file
   to state 1).

Of course, it's still possible to get into a bad situation by doing a
merge and _then_ some local mods that are not supposed to be committed.
I'd be willing to just say "so don't do that, then".

Re: diff --summarize

[Neels J Hofmeyr]

On 08/24/2011 05:38 PM, Julian Foad wrote:
> Even from a practical POV, the orthogonality is useful.  I have a script
> that generates a patch file, basically by running "svn diff", but not
> quite.  I want the files to appear in alphabetical order of their paths,
> and I want to output a list of their paths.  So my script runs "svn
> status" to find out what paths will appear in the diff, and then runs
> "svn diff" on one at a time.  If it can run "diff --summarize" instead
> of "status", then it can be trivially extended to work on repos paths,
> where at the moment it only supports WC paths.

heh yeah, you actually gave me that script back in the days, and with lesser
tweaks, I use that code all the time to semi-auto-generate my log messages
for svn patches :) It's not always precise, but it's easy to spot the errors
when reading through the diff (and the errors follow a pattern). It has
probably saved me *hours* of copy-pasting function names into log messages
by now. I really like it, thank you very much indeed.

Oh, have you by any chance made it act super precise by now? That would be a
treat.

But, I don't really understand, why do you want to semi-auto-generate a log
message for already committed revisions?

>> [[[
>> $ svn diff --summarize --old=wc/foo/ --new=wc/bar/
>> svn: E24: Sorry, svn_client_diff5 was called in a way that is not yet
>> supported
>> svn: E24: Only diffs between a path's text-base and its working files
>> are supported at this time
>> ]]]
> 
> Yes, I want us to support that.

Ok.

~Neels



signature.asc
Description: OpenPGP digital signature

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

[Neels J Hofmeyr]

On 08/24/2011 04:01 PM, Daniel Shahaf wrote:
> Neels J Hofmeyr wrote on Wed, Aug 24, 2011 at 15:32:20 +0200:
>> Changelists have been *designed* in the flipped-over wrong-way-round: they
>> *include*, not exclude selected items. We'd have to implement this against
>> its basic design. (Like using switch for externals, remember?)
> 
> Changelists were designed to group files.  What's fundamentally flawed in
> 
> % svn cl foo A/mu ./iota
> % svn commit --depth=empty A/mu ./iota --except-cl=foo

Usually the code goes like "if there is a changelist, act on the node only
when it is part of the changelist." ...well, it's just what I remember
faintly, admittedly. Is that true?

If it isn't, there's nothing wrong with your command at all. In fact that
would be quite nice.

But from the ignore-on-commit perspective, you still need to remember to
supply it at commit time.
You'd need to make the changelist always secretly self-acting, and thus the
changelist must have a special name, as Hyrum kindly pointed out :)
If I can instead create a simple property to achieve the same, I'm happier.

And your command example doesn't give you the ability to propagate it
globally without even coding a single additional line of code. (none except
warning messages we may want to introduce.)



signature.asc
Description: OpenPGP digital signature

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

[Branko Čibej]

On 24.08.2011 19:56, Mark Phippard wrote:
> On Wed, Aug 24, 2011 at 1:50 PM, Stefan Sperling  > wrote:
>
>
> I don't like this because it only addresses the merge-meister use
> case.
> Developers perform merges, too.
> The developer who does not want to commit local changes that
> existed prior
> to the merge now has to be careful to put files back on hold after the
> merge command has removed files from the special changelist.
>
>
>
> We could probably go round and round on this forever if we want to, right?

Maybe it's time to just drop it and concentrate on 1.7.0? This thread
has become way too long to follow, and some of the things I read are
such blathering nonsense that it doesn't bear mentioning.

I suggest everyone just steps away from this and lets it cool down for a
month or two, /then/ come up with a proper feature proposal.

-- Brane

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

[Mark Phippard]

On Wed, Aug 24, 2011 at 1:50 PM, Stefan Sperling  wrote:

>
> I don't like this because it only addresses the merge-meister use case.
> Developers perform merges, too.
> The developer who does not want to commit local changes that existed prior
> to the merge now has to be careful to put files back on hold after the
> merge command has removed files from the special changelist.
>


We could probably go round and round on this forever if we want to, right?
 I could just as easily say that the inexperienced developer is less likely
to be doing merges, so we do not need to optimize for them.  Or I could say
that it is better that the credentials of an inexperienced developer are
committed to the repository, then having them not commit a critical
configuration change.

I think the greater point is that this issue is more complicated than it
sounded originally, which is why I also point out we do not HAVE to do
anything at all.  Neels will say what is it going to hurt to have a feature
that someone does not have to use.  I say it hurts us anytime we add a
feature that can create confusion and problems.  Who is to say some
developer does not add this property to address their needs and then this
gets rippled out to everyone and creates problems for them that the
developer did not consider.  We are the ones that are going to be left to
answer it.  We really want our answer to be that you do not have to use the
feature or you can write a hook to make sure no one does?  BTW, that hook
would not be trivial.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

[Stefan Sperling]

On Wed, Aug 24, 2011 at 01:33:33PM -0400, Mark Phippard wrote:
> You are thinking about this from the perspective of a developer and having
> them not accidentally commit their password.  I am thinking of this from a
> merge meister type persona that has a clean working copy and is simply
> handling the merge tasks for a release.  They would merge some revisions and
> do a commit that does not include all the changes.  Other than some warnings
> they do not read, they would have no idea they lost changes.

I recognise that this can be a problem.

However, the merge meisters I've met are usually more competent
in using svn than the average developer in the same organisation.
Often they're even the local svn gurus. I would trust them to give
special consideration for files with svn:hold.
If the merge meister cannot handle this it's possible to fall back
to the template solution people are using now.

> Changelists potentially solve this problem in two distinct ways:
> 
> 1) Suppose all we implement is a client-side changelist feature (like
> TortoiseSVN).  In my scenario, since this is a client-initiated manual
> process it simply does not apply because the user has never set them up.

Right.

> 2) Suppose we add some automation, so that certain files are places on
> changelists automatically.  Because we have two pieces to the puzzle, the
> changelist and the metadata that automatically puts the file on the
> changelist, we have more flexibility.  Merge could simply be extended to
> automatically remove files from this special changelist.  Likewise, commit
> could automatically put the files back on the changelist.

I don't like this because it only addresses the merge-meister use case.
Developers perform merges, too.
The developer who does not want to commit local changes that existed prior
to the merge now has to be careful to put files back on hold after the
merge command has removed files from the special changelist.

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

[Mark Phippard]

On Wed, Aug 24, 2011 at 1:26 PM, Stefan Sperling  wrote:

> On Wed, Aug 24, 2011 at 01:12:26PM -0400, Mark Phippard wrote:
> > On Wed, Aug 24, 2011 at 1:09 PM, Stefan Sperling  wrote:
> >
> > > On Wed, Aug 24, 2011 at 12:05:00PM -0400, Mark Phippard wrote:
> > > > Merge remains a problem.  Namely that if merge updates files with the
> > > > svn:hold property the changes to those files will not be committed.
> > >
> > > I would say just let it be that way. It shouldn't matter whether
> > > local mods come from merges or from manual edits.
> > >
> > > If the changes being merged into a held file are important,
> > > then there's a user error -- the file should probably not
> > > have been held in the first place.
> > >
> >
> > I disagree.  When I have wanted this feature in the past it has been for
> > server apps where I have a default configuration file with various
> > properties.  Developers often need to insert passwords in these files and
> do
> > not want to commit, but it is very common for the file to evolve over
> time
> > and add new properties etc.  I would want and expect those values to
> merge
> > and commit between branches.
>
> What is so special about merge? A merge creates local changes.
> In the proposed design/implementation you can commit any local
> changes by passing the --do-not-hold option.
>
> Suppose you have a local file my-db.conf which contains a secret
> database password as a local change.
> You merge from another branch, and this sets the svn:eol-style
> property on this file.
> You want to keep the propchange, but don't want to commit the
> password.
>
> The solution is to temporarily remove the password from the file,
> commit the file (i.e. just the propchange) with --do-not-hold,
> and then add the password back.
>

You are thinking about this from the perspective of a developer and having
them not accidentally commit their password.  I am thinking of this from a
merge meister type persona that has a clean working copy and is simply
handling the merge tasks for a release.  They would merge some revisions and
do a commit that does not include all the changes.  Other than some warnings
they do not read, they would have no idea they lost changes.


>
> I don't see how changelists could make this any easier. Could they?
>

Changelists potentially solve this problem in two distinct ways:

1) Suppose all we implement is a client-side changelist feature (like
TortoiseSVN).  In my scenario, since this is a client-initiated manual
process it simply does not apply because the user has never set them up.

2) Suppose we add some automation, so that certain files are places on
changelists automatically.  Because we have two pieces to the puzzle, the
changelist and the metadata that automatically puts the file on the
changelist, we have more flexibility.  Merge could simply be extended to
automatically remove files from this special changelist.  Likewise, commit
could automatically put the files back on the changelist.


-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

[Stefan Sperling]

On Wed, Aug 24, 2011 at 01:12:26PM -0400, Mark Phippard wrote:
> On Wed, Aug 24, 2011 at 1:09 PM, Stefan Sperling  wrote:
> 
> > On Wed, Aug 24, 2011 at 12:05:00PM -0400, Mark Phippard wrote:
> > > Merge remains a problem.  Namely that if merge updates files with the
> > > svn:hold property the changes to those files will not be committed.
> >
> > I would say just let it be that way. It shouldn't matter whether
> > local mods come from merges or from manual edits.
> >
> > If the changes being merged into a held file are important,
> > then there's a user error -- the file should probably not
> > have been held in the first place.
> >
> 
> I disagree.  When I have wanted this feature in the past it has been for
> server apps where I have a default configuration file with various
> properties.  Developers often need to insert passwords in these files and do
> not want to commit, but it is very common for the file to evolve over time
> and add new properties etc.  I would want and expect those values to merge
> and commit between branches.

What is so special about merge? A merge creates local changes.
In the proposed design/implementation you can commit any local
changes by passing the --do-not-hold option.

Suppose you have a local file my-db.conf which contains a secret
database password as a local change.
You merge from another branch, and this sets the svn:eol-style
property on this file.
You want to keep the propchange, but don't want to commit the
password.

The solution is to temporarily remove the password from the file,
commit the file (i.e. just the propchange) with --do-not-hold,
and then add the password back.

I don't see how changelists could make this any easier. Could they?

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

[Mark Phippard]

On Wed, Aug 24, 2011 at 1:09 PM, Stefan Sperling  wrote:

> On Wed, Aug 24, 2011 at 12:05:00PM -0400, Mark Phippard wrote:
> > Merge remains a problem.  Namely that if merge updates files with the
> > svn:hold property the changes to those files will not be committed.
>
> I would say just let it be that way. It shouldn't matter whether
> local mods come from merges or from manual edits.
>
> If the changes being merged into a held file are important,
> then there's a user error -- the file should probably not
> have been held in the first place.
>

I disagree.  When I have wanted this feature in the past it has been for
server apps where I have a default configuration file with various
properties.  Developers often need to insert passwords in these files and do
not want to commit, but it is very common for the file to evolve over time
and add new properties etc.  I would want and expect those values to merge
and commit between branches.



-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

[Stefan Sperling]

On Wed, Aug 24, 2011 at 12:05:00PM -0400, Mark Phippard wrote:
> There is nothing wrong with adding it and I believe I have said that.  I
> have also said that I was in favor of solving the issue.  All I am saying is
> that Neels has done some good work looking at what that feature means in its
> entirety and he has uncovered a number of things to consider. He happens to
> not think they are a big deal, which is fine.  I am simply saying that one
> option we have is to not implement the feature until we have a better answer
> for those considerations.

OK, we're on the same page then.
I agree we need to agree on the points that are still unclear.

> Merge remains a problem.  Namely that if merge updates files with the
> svn:hold property the changes to those files will not be committed.

I would say just let it be that way. It shouldn't matter whether
local mods come from merges or from manual edits.

If the changes being merged into a held file are important,
then there's a user error -- the file should probably not
have been held in the first place.

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

[Mark Phippard]

On Wed, Aug 24, 2011 at 11:44 AM, Stefan Sperling  wrote:

> On Wed, Aug 24, 2011 at 11:08:34AM -0400, Mark Phippard wrote:
> > I do not think we HAVE to do this feature.  It would be nice, but it
> seems
> > to raise some challenging problems that make it less nice.  Personally, I
> > just think we should not do anything, including the changelists, and
> leave
> > the recommendation of using a template.
>
> What's wrong with adding this feature when there are clearly
> people who need it? If the template solution covered all needs
> this thread wouldn't even exist.
>

There is nothing wrong with adding it and I believe I have said that.  I
have also said that I was in favor of solving the issue.  All I am saying is
that Neels has done some good work looking at what that feature means in its
entirety and he has uncovered a number of things to consider. He happens to
not think they are a big deal, which is fine.  I am simply saying that one
option we have is to not implement the feature until we have a better answer
for those considerations.  That is all I am saying.  If implementing the
feature requires us to do a bunch of ugly things we do not like, then maybe
we just should not do it until we have a better answer.

We seem to be in agreement that this feature should not impact update.  So
that is one problem off the table.  AFAIK, there are open issues asking for
this though so we have to be in agreement we do NOT agree that this should
be done.

Merge remains a problem.  Namely that if merge updates files with the
svn:hold property the changes to those files will not be committed.  I think
the changelist design gives us more options in this area, but maybe they are
too hacky.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

[Stefan Sperling]

On Wed, Aug 24, 2011 at 11:08:34AM -0400, Mark Phippard wrote:
> I do not think we HAVE to do this feature.  It would be nice, but it seems
> to raise some challenging problems that make it less nice.  Personally, I
> just think we should not do anything, including the changelists, and leave
> the recommendation of using a template.

What's wrong with adding this feature when there are clearly
people who need it? If the template solution covered all needs
this thread wouldn't even exist.

Overall, I think this thread got hung up in details.
It seems a bit early to discuss implementation details (changelists
vs. props) when there isn't even agreement on the desired feature set.
Can we focus on that first, and then argue about how to implement it?

In http://svn.haxx.se/dev/archive-2011-08/0469.shtml Julian suggested
to create a document in style of a referance manual to document what
we really want. I think this would be a good next step if it hasn't
already happened.

My own view on this is as follows:

Ideas floating in this thread have covered behaviour of commit, update,
diff, status, merge, and repository-wide configuration of held nodes.

In my mind, the most important items are, in order:
 - behaviour of commit
 - repository-wide configuration of held nodes

I think we should initially aim for some minimal solution which
addresses these points and leaves room for further extension.
I don't really care how it's implemented.

Making additional subcommands do fancy things with held-back nodes is
nice but not really necessary to solve the problems this feature is
supposed to address.

Re: diff --summarize

[Julian Foad]

Neels J Hofmeyr wrote:
> I've examined your patch and did add something to wc_wc_diff_summarize,
> though it's not as plain as I first thought.
> 
> I'll give you the elephant in the room first:
> 
> Currently, 'svn diff --summarize ' does *nothing else* than what a
> plain 'svn status' does. There is no way to get other wc-wc-diffs than the
> diff between BASE and WORKING/ACTUAL. So at this point in time, we could
> redirect diff_wc_wc_summarize to client_status and basically no-one would
> notice anything.

Yes, that's true: it provides little or no added value over 'status'.
It's also inconsistent with 'status' in minor ways, e.g. it prints 'A'
and 'D' for a replacement whereas 'status' prints 'R'.  I noticed that,
and briefly wondered if there could be a way to combine the 'diff
--summarize' and 'status' code paths, but that's not the way to go.

The alternative and attractive option is (one day) to extend 'diff' to
be able to diff two arbitrary trees (in the repos and/or WC and/or
unversioned), and then 'diff --summarize' automatically gets that
ability too.

> This whole local --summarize only even *begins* to make sense when we can
> compare one subpath of a WC to another subpath, or even one checkout with a
> different checkout (i.e. locally compare between completely different WCs).

That stuff is lovely, I'd really like to see it.  In some ways the local
summarize implementation restricted to a BASE-WORKING diff is totally
pointless because it just does what 'status' can do, but from an
architectural POV it is really important.

Even from a practical POV, the orthogonality is useful.  I have a script
that generates a patch file, basically by running "svn diff", but not
quite.  I want the files to appear in alphabetical order of their paths,
and I want to output a list of their paths.  So my script runs "svn
status" to find out what paths will appear in the diff, and then runs
"svn diff" on one at a time.  If it can run "diff --summarize" instead
of "status", then it can be trivially extended to work on repos paths,
where at the moment it only supports WC paths.


> Now back to pretending diff --summarize  *is* in fact useful in
> itself:
> 
> So I thought, during wc-wc diff, it would make sense to also have a
> text_deltas flag, so we don't need to do the keywords/nl translations. So I
> coded that. While I did, I hit this comment:
> 
> /* Note that this might be the _second_ time we translate
>the file, as svn_wc__internal_file_modified_p() might have used a
>tmp translated copy too.  But what the heck, diff is
>already expensive, translating twice for the sake of code
>modularity is liveable. */
> 
> So there's this thing where diff translates pristine&working *anyway* to
> determine if they are different. That's just the check whether to skip the 
> file.
> 
> Then it translates them *again* to do the diff. And I think the "is it
> modified?" test uses streamy translation and the diff-producing part uses
> translation to a tempfile.
> 
> So there's room for optimization there. Translate them only once, for
> comparison, if that's needed, and keep the result for producing the diff.

Ugh.  Good catch.  Room for improvement there, for sure.

> So all my part of the patch does is skip the second translation if
> text_deltas is false. The first translation can't generally be skipped since
> it determines the text-modified status. It has its own skip semantics.
> 
> Looking at svn_wc__internal_file_modified_p()'s (the first translation's)
> heuristics to shortcut the decision whether a file was modified:
> - shortcut to "yes, modified" when
>- there is no pristine
>- the WC status gives away a modification
> - shortcut to "no, not modified" when
>- filesize and timestamp unchanged
> - else translate and compare
> 
> So if it shortcuts to "yes, modified", the later diff-translation is the
> only translation. (1)
> If it shortcuts to "no, not modified", the diff-translation is always
> skipped as there is no diff.
> Else, basically if there are only text mods (which can only be verified
> after translation) there are always two translations. (2)
> 
> So this patch makes local-diff translation-free in (1), and removes one of
> the two translations, i.e. removes the tempfile-based diff-producing
> translation, in (2).
> 
> Considering that actually, in most default cases (with the lack of
> keywords/nl props), there is *no* translation at all and the callbacks get
> the direct pristine and working copy paths, my patch *is* a bit overkill.
> 
> But when a user is coming from the other side, say if translating their
> files takes a really really long time, well, this might be a noticeable
> speedup seen on --summarize. Same of which is obtained by running 'status'.
> 
> ...If I haven't confused you too much by now, do you think it's worth
> touching wc_wc diff like my patch does?

OK, I think this optimization is certainly worth considering.  I haven't
looke

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

[Mark Phippard]

On Wed, Aug 24, 2011 at 11:08 AM, Mark Phippard  wrote:

> On Wed, Aug 24, 2011 at 9:32 AM, Neels J Hofmeyr  wrote:
>
>> We'd have to change the changelists feature, beyond recognition.
>> Instead of adding a quick propget in basically one or two places,
>> we do what, overhaul changelists + plaster it with special conditions.
>>
>
> Why exactly?  It seems we can declare anything on a certain named
> changelist will be ignored from commit.  All we have to do is change the
> commit code to do this ignoring.  IOW, we could just recreate the
> TortoiseSVN feature and nothing more.  I do not see where this changes the
> changelist code.
>
> But ok, we can do that. Still, the question remains: what about Johan &
>> Co.,
>> that only have a use for ignore-on-commit if it is *centrally
>> configurable*.
>>
>
> I do not think we HAVE to do this feature.  It would be nice, but it seems
> to raise some challenging problems that make it less nice.  Personally, I
> just think we should not do anything, including the changelists, and leave
> the recommendation of using a template.
>

BTW, admins can also lock files in the repository to prevent accidental
commits of sensitive information.


-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

[Mark Phippard]

On Wed, Aug 24, 2011 at 9:32 AM, Neels J Hofmeyr  wrote:

> We'd have to change the changelists feature, beyond recognition.
> Instead of adding a quick propget in basically one or two places,
> we do what, overhaul changelists + plaster it with special conditions.
>

Why exactly?  It seems we can declare anything on a certain named changelist
will be ignored from commit.  All we have to do is change the commit code to
do this ignoring.  IOW, we could just recreate the TortoiseSVN feature and
nothing more.  I do not see where this changes the changelist code.

But ok, we can do that. Still, the question remains: what about Johan & Co.,
> that only have a use for ignore-on-commit if it is *centrally
> configurable*.
>

I do not think we HAVE to do this feature.  It would be nice, but it seems
to raise some challenging problems that make it less nice.  Personally, I
just think we should not do anything, including the changelists, and leave
the recommendation of using a template.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

[Daniel Shahaf]

Stefan Sperling wrote on Wed, Aug 24, 2011 at 16:51:43 +0200:
> On Wed, Aug 24, 2011 at 05:01:25PM +0300, Daniel Shahaf wrote:
> > Neels J Hofmeyr wrote on Wed, Aug 24, 2011 at 15:32:20 +0200:
> > > Changelists have been *designed* in the flipped-over wrong-way-round: they
> > > *include*, not exclude selected items. We'd have to implement this against
> > > its basic design. (Like using switch for externals, remember?)
> > 
> > Changelists were designed to group files.  What's fundamentally flawed in
> > 
> > % svn cl foo A/mu ./iota
> > % svn commit --depth=empty A/mu ./iota --except-cl=foo
> 
> You have to specify --except-cl every time you commit.
> With svn:hold as a property you set it once and forget about it.

I was making a general point about changelists, not about their use in
conjunction with svn:hold feature.

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

[Stefan Sperling]

On Wed, Aug 24, 2011 at 05:01:25PM +0300, Daniel Shahaf wrote:
> Neels J Hofmeyr wrote on Wed, Aug 24, 2011 at 15:32:20 +0200:
> > Changelists have been *designed* in the flipped-over wrong-way-round: they
> > *include*, not exclude selected items. We'd have to implement this against
> > its basic design. (Like using switch for externals, remember?)
> 
> Changelists were designed to group files.  What's fundamentally flawed in
> 
> % svn cl foo A/mu ./iota
> % svn commit --depth=empty A/mu ./iota --except-cl=foo

You have to specify --except-cl every time you commit.
With svn:hold as a property you set it once and forget about it.

Re: rc1 is DOA. What now?

[C. Michael Pilato]

On 08/24/2011 10:01 AM, Mark Phippard wrote:
> As I said before, I bet it would not take me too long looking through our
> open issues in the issue tracker to find a bug that was just as bad as this
> one.  If we are going to call bugs like this show stoppers it is going to be
> difficult to ever get the release out.

I won't pretend to speak on behalf of those who've voiced concerns about
this bug, but I wonder if the perceived gravity here is due to extra
sensitivity about the 'upgrade' command as the very first thing users will
try to do with Subversion 1.7.  Well, the second thing, after they try to
run 'svn update' and get an error message telling them to upgrade. ;-)

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand



signature.asc
Description: OpenPGP digital signature

Re: rc1 is DOA. What now?

[Mark Phippard]

On Wed, Aug 24, 2011 at 10:01 AM, Mark Phippard  wrote:

> This is total strawman that you are setting up just so that you can knock
> it down.  Hyrum has said on numerous occasions that he can and will merge
> bug fixes prior to creating the final 1.7.  As he pointed out in a recent
> reply this was a safe fix that was reviewed.  There was nothing that was
> going to prevent this from going into 1.7.0.  If you disagree with this
> policy, then start a new thread for it.  There are definitely going to be
> bugs found in any RC we release.  If we treat all bugs like this we will
> never release.  All we have really accomplished is to push this release off
> another week.
>

>From the Community Guide:

"At the beginning of the final week of the stabilization period, a new
release candidate tarball should be made if there are any showstopper
changes pending since the last one. The final week of the stabilization
period is reserved for critical bugfixes; fixes for minor bugs should be
deferred to the A.B.1 release. A critical bug is a non-edge-case crash, a
data corruption problem, a major security hole, or something equally
serious."

http://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

[Daniel Shahaf]

Neels J Hofmeyr wrote on Wed, Aug 24, 2011 at 15:32:20 +0200:
> Changelists have been *designed* in the flipped-over wrong-way-round: they
> *include*, not exclude selected items. We'd have to implement this against
> its basic design. (Like using switch for externals, remember?)

Changelists were designed to group files.  What's fundamentally flawed in

% svn cl foo A/mu ./iota
% svn commit --depth=empty A/mu ./iota --except-cl=foo

?

Re: rc1 is DOA. What now?

[Mark Phippard]

First off, let me just state that I have already said on several occasions I
am OK with rolling an RC2 and since that seems to be the plan I am +1 to it.
 I am not trying to get RC1 released.  That said, we could very well wind up
in this same situation again after RC2 is out so I think it is worth
continuing the discussion.

On Wed, Aug 24, 2011 at 4:38 AM, Bert Huijben  wrote:

>
> >
> > If 1.7.0 was released with this upgrade bug, you would simply have to
> > wait for a 1.7.x patch release which fixes the bug before upgrading
> > from 1.6.x.
> >
> > This is basically just like any other show stopper you might find
> > during the upgrade to 1.7. Except that you already know about it now :)
> >
> > But I understand your complaints and agree that the problem needs
> > to be fixed in 1.7.x eventually.
>
> * The average TortoiseSVN user in a corporate environment can't
> upgrade/downgrade its own installation as that as managed via automated
> distribution.
> * TortoiseSVN versions can't be installed side by side.
> (The same problem applies to big multi user installations on shared linux
> installations using plain svn)
>
> How would you answer an e-mail from your sysadmin that tonight before you
> go
> home you have to remove all locks from all your working copies because
> otherwise tomorrow your working copies are broken?
> (Assuming you have over 40 independent working copies, not counting
> possible
> directory externals, like I had when I worked at TCG)
>

This is total strawman that you are setting up just so that you can knock it
down.  Hyrum has said on numerous occasions that he can and will merge bug
fixes prior to creating the final 1.7.  As he pointed out in a recent reply
this was a safe fix that was reviewed.  There was nothing that was going to
prevent this from going into 1.7.0.  If you disagree with this policy, then
start a new thread for it.  There are definitely going to be bugs found in
any RC we release.  If we treat all bugs like this we will never release.
 All we have really accomplished is to push this release off another week.

Back to the strawman, you create this scenario of a poor admin that is
rolling out an update to all these workstations.  Since when do these people
immediately roll out .0 releases?  Since when do these people not do any
testing or investigation of their own?  Even if this fix did not make it
into a .0 it would have been in a .1.  It also does not factor in that users
can still checkout new working copies etc.

I call this a show stopper; and as I suggested before suggesting these users
> to wait until 1.7.1 is the same as calling this a show stopper.
> And it also breaks the perfect stability track record we had with a
> known-in-advance broken release.
>


As I said before, I bet it would not take me too long looking through our
open issues in the issue tracker to find a bug that was just as bad as this
one.  If we are going to call bugs like this show stoppers it is going to be
difficult to ever get the release out.


-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: svn_fs_verify() in 1.7.0

[C. Michael Pilato]

On 08/24/2011 09:37 AM, Daniel Shahaf wrote:
> svn_fs_verify() is sitting in 1.7.x/STATUS, as does a branch to extend
> it with progress reporting.  Both of these are API changes, ie, if they
> don't get into an rc they should be withdrawn from STATUS.
> 
> Is anyone other than Bert and I planning to review/vote for those?

I'll take a look at them.

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand



signature.asc
Description: OpenPGP digital signature

Re: rc1 is DOA. What now?

[Daniel Shahaf]

Bert Huijben wrote on Wed, Aug 24, 2011 at 15:18:49 +0200:
> 
> 
> > -Original Message-
> > From: Branko Čibej [mailto:br...@xbc.nu] On Behalf Of Branko Cibej
> > Sent: woensdag 24 augustus 2011 15:07
> > To: Bert Huijben
> > Subject: Re: rc1 is DOA. What now?
> > 
> > On 24.08.2011 10:38, Bert Huijben wrote:
> > > How would you answer an e-mail from your sysadmin that tonight before
> > you go
> > > home you have to remove all locks from all your working copies because
> > > otherwise tomorrow your working copies are broken?
> > 
> > I would mail his manager with a suggestion to fire that sysadmin,
> > because he wasn't doing his job right.
> > 
> > > I call this a show stopper; and as I suggested before suggesting these 
> > > users
> > > to wait until 1.7.1 is the same as calling this a show stopper.
> > > And it also breaks the perfect stability track record we had with a
> > > known-in-advance broken release.
> > >
> > > In my opinion this issue must be fixed by 1.7.0.
> > 
> > You're overreacting. Compare this limitation to all the other
> > limitations of the 1.7 WC upgrade (by the way, where's the list of those
> > anyway?).
> 
> The complete list:
> * You can't have loggy items queued in your working copy
> 
> All other working copy states are fully supported for upgrade for the step 
> from 1.0-1.6 -> 1.7+
> 
> There are unsupported scenarios for the intermediate development formats, but 
> there are no other limitations for the supported formats.
> 
>   Bert
> 

Documented in r1161100.

svn_fs_verify() in 1.7.0

[Daniel Shahaf]

svn_fs_verify() is sitting in 1.7.x/STATUS, as does a branch to extend
it with progress reporting.  Both of these are API changes, ie, if they
don't get into an rc they should be withdrawn from STATUS.

Is anyone other than Bert and I planning to review/vote for those?

Re: rc1 is DOA. What now?

[C. Michael Pilato]

On 08/24/2011 07:38 AM, Hyrum K Wright wrote:
> So the grander feeling seems to be: scuttle rc1 (which already has the
> votes for release) and reroll an rc2.  The fix for the 'upgrade with
> lock' issue is already on 1.7.x, so we can do this pretty much
> whenever we'd like.  I'm inclined to do it tomorrow, following the
> normal pattern.

+1.

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand



signature.asc
Description: OpenPGP digital signature

svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)

[Neels J Hofmeyr]

I don't get why you guys are even considering changelists :)
What's the killer trait of changelists that makes this pig fly higher than a
single lightweight boolean prop? I don't see one.

I think using changelists will end up being a Dirty Hack, either
inconvenient or overly special-cased, no middle way available. It will spawn
a lot of impenetrable code, compared to just a propget.

If you're interested, read these elaborate reasons...


Changelists have been *designed* in the flipped-over wrong-way-round: they
*include*, not exclude selected items. We'd have to implement this against
its basic design. (Like using switch for externals, remember?)

Mark Phippard also talked about this kind of solution, adding a special
changelist to exclude items from commit. I've thought it through long before
proposing the svn:hold prop. My argument still holds:

We'd have to change the changelists feature, beyond recognition.
Instead of adding a quick propget in basically one or two places,
we do what, overhaul changelists + plaster it with special conditions.

But ok, we can do that. Still, the question remains: what about Johan & Co.,
that only have a use for ignore-on-commit if it is *centrally configurable*.
You say, jolly, we just add the same prop neels proposed, to manipulate
local changelists. But the prop alone is able to do the exact same thing
without even touching changelists, and in fact would achieve the same goal
with just a tiny patch of code; most of the infrastructure is already there,
entirely for free, *exactly* in the way it is needed, no flipside
special-casing required.

User says: "what, I need to set a changelist *and* a prop? o_O"

If we're *anyway* going to have a prop, which *does* provide all information
needed, then I don't see any need to complicate this. If you're so eager to
have a local-only implementation, just keep the prop out of the repos.
(I wouldn't push that beyond telling users to add a pre-commit hook, though.)

Do changelists make anything easier?

- Yes, might spare us adding an 'H' notification on 'status'.

- Changelists are kept out of version control. But svn:ignore-on-commit will
be only as long as it remains a local feature. The exact same is achieved
when the svn:hold propset is simply never committed.

- No, changelists do not solve the 'merge-held-items' situation. After
getting a merge in on an svn:ignore-on-commit'ed file, it is still not
committed along with the rest of the merge, just like with a plain prop.
Furthermore, if you do force a commit, then, guess what, the items silently
disappear from the 'ignore-on-commit' changelist! Due to their basic design!
Unless we add yet another special case there. Ugh.
Or the merger person has to remember which they were and adds them back to
the list manually. Ugh.
You could argue that the global 'svn:hold' prop is still set, and after a
merge-commit, you can automatically add those back to the changelist. I
think this is a far more complex, slow and error-prone solution than what I
proposed (just flag those files that were on hold and also received a merge,
and block the commit until the user explicitly decides what to do, using a
given cmdline option. Or by removing flags manually if desired).

- (Sure, implementing this might gain the changelists feature some useful
cmdline options, *if* we implement them in a general fashion instead of
triggering on a special name only. -- that's besides the point though.)

- (I guess that setting a prop on a node directly potentially makes faster
code than employing a look-up in a special list. But this might actually not
be true.)


-1, IMO we should totally not have an svn:ignore-on-commit changelist.
Though Tortoise devs might have liked that :)

~Neels



signature.asc
Description: OpenPGP digital signature

RE: rc1 is DOA. What now?

[Bert Huijben]

> -Original Message-
> From: Branko Čibej [mailto:br...@xbc.nu] On Behalf Of Branko Cibej
> Sent: woensdag 24 augustus 2011 15:07
> To: Bert Huijben
> Subject: Re: rc1 is DOA. What now?
> 
> On 24.08.2011 10:38, Bert Huijben wrote:
> > How would you answer an e-mail from your sysadmin that tonight before
> you go
> > home you have to remove all locks from all your working copies because
> > otherwise tomorrow your working copies are broken?
> 
> I would mail his manager with a suggestion to fire that sysadmin,
> because he wasn't doing his job right.
> 
> > I call this a show stopper; and as I suggested before suggesting these users
> > to wait until 1.7.1 is the same as calling this a show stopper.
> > And it also breaks the perfect stability track record we had with a
> > known-in-advance broken release.
> >
> > In my opinion this issue must be fixed by 1.7.0.
> 
> You're overreacting. Compare this limitation to all the other
> limitations of the 1.7 WC upgrade (by the way, where's the list of those
> anyway?).

The complete list:
* You can't have loggy items queued in your working copy

All other working copy states are fully supported for upgrade for the step from 
1.0-1.6 -> 1.7+

There are unsupported scenarios for the intermediate development formats, but 
there are no other limitations for the supported formats.

Bert

Re: rc1 is DOA. What now?

[Branko Čibej]

On 24.08.2011 14:17, Julian Foad wrote:
> Hyrum K Wright wrote:
>> On Wed, Aug 24, 2011 at 6:07 AM, Julian Foad  
>> wrote:
>>> Having read the discussion elsethread, I now consider this a blocker and
>>> that also seems to be the consensus.  So we can't release 1.7.0 with
>>> this bug; it has to be fixed.  That in turn means the supposed 'RC1' is
>>> no longer an RC at all.  [...]
>> So the grander feeling seems to be: scuttle rc1 (which already has the
>> votes for release)
> I interpreted Bert's "+1 as it passes regression tests but -1 to release
> as Subversion 1.7.0" the same as a "-1" vote for RC1, based on my
> understanding of the requirements for an RC.
>
> To make it plain, I hereby change my own RC1 vote to -1.

Looks like you guys are going to dither around a minor point so much
that the RC soak is going to last as long as the rest of the 1.7 cycle.
Are you quite sure you won't change your mind tomorrow? :)

-- Brane

Re: [PATCH] svnmucc doesn't honor --config-dir for auth stuff

[Daniel Shahaf]

[ Please send attachments as text/plain (eg, *.txt) so that our mailers
show them inline when reading/replying.  Thanks. ]

Roderich Schupp wrote on Wed, Aug 24, 2011 at 14:28:46 +0200:
> Hi,
> 
> svnmucc doesn't honor option --config-dir when it comes to stuff
> stored below config_dir/auth.
> 
> To reproduce:
> - access a remote repository that will store information below
> config_dir/auth, e.g.
>   username/password or permanently accepted SSL server certificate,
> using svn command
>   without --config-dir  (i.e. default config_dir ~/.subversion is used)
> - try to access the same repository with "svnmucc --config-dir
> /non/existent/directory ..."
>   and wonder why svnmucc doesn't prompt again for the above information
> 
> Suggested patch against trunk attached.
> 
> [[[
> Make svnmucc honor option --config-dir for auth stuff.
> 
> * tools/client-side/svnmucc/svnmucc.c
>   (create_ra_callbacks) Add parameter config_dir, pass it to
> svn_cmdline_create_auth_baton.
>   (execute) Pass config_dir to create_ra_callbacks.
> ]]]
> 
> 
> Cheers, Roderich

> --- tools/client-side/svnmucc/svnmucc.c.orig  2011-08-24 09:26:34.933787000 
> +0200
> +++ tools/client-side/svnmucc/svnmucc.c   2011-08-24 09:30:43.188708000 
> +0200
> @@ -108,6 +108,7 @@
>  create_ra_callbacks(svn_ra_callbacks2_t **callbacks,
>  const char *username,
>  const char *password,
> +const char *config_dir,
>  svn_boolean_t non_interactive,
>  svn_boolean_t no_auth_cache,
>  apr_pool_t *pool)
> @@ -116,7 +117,7 @@
>  
>SVN_ERR(svn_cmdline_create_auth_baton(&(*callbacks)->auth_baton,
>  non_interactive,
> -username, password, NULL, 
> no_auth_cache,
> +username, password, config_dir, 
> no_auth_cache,
>  FALSE, NULL, NULL, NULL, pool));
>  
>(*callbacks)->open_tmp_file = open_tmp_file;
> @@ -635,7 +636,7 @@
>SVN_ERR(svn_config_get_config(&config, config_dir, pool));
>SVN_ERR(svn_cmdline__apply_config_options(config, config_options,
>  "svnmucc: ", "--config-option"));
> -  SVN_ERR(create_ra_callbacks(&ra_callbacks, username, password,
> +  SVN_ERR(create_ra_callbacks(&ra_callbacks, username, password, config_dir,
>non_interactive, no_auth_cache, pool));
>SVN_ERR(svn_ra_open4(&session, NULL, anchor, NULL, ra_callbacks,
> NULL, config, pool));

Philip just applied the patch.

There seem to be further opportunities for improvement here, though:

- The FALSE/NULL parameters to svn_cmdline_create_auth_baton().  At
  least the CONFIG parameter could be easily populated too, since the
  caller already has a config hash.

- If ~/.subversion is unreadable (chmod 0), then svnmucc just errors out.
  (We fixed that for 'svn' some time ago; now it only issues a warning.)

Re: [PATCH] svnmucc doesn't honor --config-dir for auth stuff

[Philip Martin]

Roderich Schupp  writes:

> [[[
> Make svnmucc honor option --config-dir for auth stuff.
>
> * tools/client-side/svnmucc/svnmucc.c
>   (create_ra_callbacks) Add parameter config_dir, pass it to
> svn_cmdline_create_auth_baton.
>   (execute) Pass config_dir to create_ra_callbacks.
> ]]]

Committed in r1161080. Thanks!

> --- tools/client-side/svnmu/svnmucc.c.orig2011-08-24 09:26:34.933787000 
> +0200
> +++ tools/client-side/svnmu/svnmucc.c 2011-08-24 09:30:43.188708000 +0200
> @@ -108,6 +108,7 @@

Something mangled the patch slightly: one of the path components is
truncated.

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com

Re: dump svn:hold, long live file externals?? (and discussing recursive hold) -- was: bring on your concerns about svn:hold, please

[Julian Foad]

Daniel Shahaf wrote:
> Julian Foad wrote on Wed, Aug 24, 2011 at 13:23:53 +0100:
> > On Wed, 2011-08-24 at 15:10 +0300, Daniel Shahaf wrote:
> > > Julian Foad wrote on Wed, Aug 24, 2011 at 11:13:09 +0100:
> > > > The set of changelists to use is already passed into the libsvn_client
> > > > API from the client.  Pretty much all we need is a way to specify sets
> > > > of changelists more flexibly.  For the main functionality, the 'commit'
> > > > subcommand would specify "select everything except changelist
> > > > 'svn:ignore-on-commit'" unless overridden.  That would make the file be
> > > 
> > > Does this require negative changelists?  Currently changelists are
> > > 'select only members of this changelist', but you're proposing 'select 
> > > except
> > > members of this changelist'.
> > 
> > Yes.  [...] So semantically it's not
> > new.  It does need an API change of one kind or another.
> 
> Fair enough.
> 
> For simplicity, we can retain the status quo where no changelists are
> allowed on directories?  Otherwise we'd have to decide how a negative
> changelist behaves when applied to a directory.

Yes, I'm assuming we retain the status quo.

- Julian


> (It could mean changelists are to be coupled with a depth value; but
> let's not open that can of worms unless we have to.)

Re: dump svn:hold, long live file externals?? (and discussing recursive hold) -- was: bring on your concerns about svn:hold, please

[Daniel Shahaf]

Julian Foad wrote on Wed, Aug 24, 2011 at 13:23:53 +0100:
> On Wed, 2011-08-24 at 15:10 +0300, Daniel Shahaf wrote:
> > Julian Foad wrote on Wed, Aug 24, 2011 at 11:13:09 +0100:
> > > > > C. Michael Pilato wrote:
> > > > >> So back to what I would consider the primary deliverable of interest 
> > > > >> here:
> > > > >> avoiding one's own accidental commits.  I'm leaning toward [...]  A
> > > > >> special changelist honored by our libsvn_client code which does what 
> > > > >> we're
> > > > >> talking about here, shows up in 'svn status' like the others do, 
> > > > >> requires
> > > > >> very little additional infrastructure, for which state changes are 
> > > > >> not
> > > > >> versioned operations (such as they would be with the commits of the 
> > > > >> addition
> > > > >> and removal of an svn:hold property), etc.
> > > 
> > > I like the sound of this, too, as the local-only part of the solution.
> > > See below for the centralized part of the solution.
> > > 
> > > The set of changelists to use is already passed into the libsvn_client
> > > API from the client.  Pretty much all we need is a way to specify sets
> > > of changelists more flexibly.  For the main functionality, the 'commit'
> > > subcommand would specify "select everything except changelist
> > > 'svn:ignore-on-commit'" unless overridden.  That would make the file be
> > 
> > Does this require negative changelists?  Currently changelists are
> > 'select only members of this changelist', but you're proposing 'select 
> > except
> > members of this changelist'.
> 
> Yes.  If that sounds like a non-trivial extension of the changelist
> semantics, it's not.  Imagine we have an API to retrieve a list of all
> the changelist names and a pseudo-changelist indicator to denote "files
> that are not in any changelist".  Then we could simply map that request
> into a select-multiple-changelists request.  So semantically it's not
> new.  It does need an API change of one kind or another.
> 

Fair enough.

For simplicity, we can retain the status quo where no changelists are
allowed on directories?  Otherwise we'd have to decide how a negative
changelist behaves when applied to a directory.

(It could mean changelists are to be coupled with a depth value; but
let's not open that can of worms unless we have to.)

> - Julian
> 
> 

[PATCH] svnmucc doesn't honor --config-dir for auth stuff

[Roderich Schupp]

Hi,

svnmucc doesn't honor option --config-dir when it comes to stuff
stored below config_dir/auth.

To reproduce:
- access a remote repository that will store information below
config_dir/auth, e.g.
  username/password or permanently accepted SSL server certificate,
using svn command
  without --config-dir  (i.e. default config_dir ~/.subversion is used)
- try to access the same repository with "svnmucc --config-dir
/non/existent/directory ..."
  and wonder why svnmucc doesn't prompt again for the above information

Suggested patch against trunk attached.

[[[
Make svnmucc honor option --config-dir for auth stuff.

* tools/client-side/svnmucc/svnmucc.c
  (create_ra_callbacks) Add parameter config_dir, pass it to
svn_cmdline_create_auth_baton.
  (execute) Pass config_dir to create_ra_callbacks.
]]]


Cheers, Roderich


svnmucc.patch
Description: Binary data

Re: dump svn:hold, long live file externals?? (and discussing recursive hold) -- was: bring on your concerns about svn:hold, please

[Julian Foad]

On Wed, 2011-08-24 at 15:10 +0300, Daniel Shahaf wrote:
> Julian Foad wrote on Wed, Aug 24, 2011 at 11:13:09 +0100:
> > > > C. Michael Pilato wrote:
> > > >> So back to what I would consider the primary deliverable of interest 
> > > >> here:
> > > >> avoiding one's own accidental commits.  I'm leaning toward [...]  A
> > > >> special changelist honored by our libsvn_client code which does what 
> > > >> we're
> > > >> talking about here, shows up in 'svn status' like the others do, 
> > > >> requires
> > > >> very little additional infrastructure, for which state changes are not
> > > >> versioned operations (such as they would be with the commits of the 
> > > >> addition
> > > >> and removal of an svn:hold property), etc.
> > 
> > I like the sound of this, too, as the local-only part of the solution.
> > See below for the centralized part of the solution.
> > 
> > The set of changelists to use is already passed into the libsvn_client
> > API from the client.  Pretty much all we need is a way to specify sets
> > of changelists more flexibly.  For the main functionality, the 'commit'
> > subcommand would specify "select everything except changelist
> > 'svn:ignore-on-commit'" unless overridden.  That would make the file be
> 
> Does this require negative changelists?  Currently changelists are
> 'select only members of this changelist', but you're proposing 'select except
> members of this changelist'.

Yes.  If that sounds like a non-trivial extension of the changelist
semantics, it's not.  Imagine we have an API to retrieve a list of all
the changelist names and a pseudo-changelist indicator to denote "files
that are not in any changelist".  Then we could simply map that request
into a select-multiple-changelists request.  So semantically it's not
new.  It does need an API change of one kind or another.

- Julian

Re: rc1 is DOA. What now?

[Julian Foad]

Hyrum K Wright wrote:
> On Wed, Aug 24, 2011 at 6:07 AM, Julian Foad  wrote:
> > Having read the discussion elsethread, I now consider this a blocker and
> > that also seems to be the consensus.  So we can't release 1.7.0 with
> > this bug; it has to be fixed.  That in turn means the supposed 'RC1' is
> > no longer an RC at all.  [...]
> 
> So the grander feeling seems to be: scuttle rc1 (which already has the
> votes for release)

I interpreted Bert's "+1 as it passes regression tests but -1 to release
as Subversion 1.7.0" the same as a "-1" vote for RC1, based on my
understanding of the requirements for an RC.

To make it plain, I hereby change my own RC1 vote to -1.

>  and reroll an rc2.  The fix for the 'upgrade with
> lock' issue is already on 1.7.x, so we can do this pretty much
> whenever we'd like.  I'm inclined to do it tomorrow, following the
> normal pattern.

+1 to that.

- Julian

Re: dump svn:hold, long live file externals?? (and discussing recursive hold) -- was: bring on your concerns about svn:hold, please

[Daniel Shahaf]

Julian Foad wrote on Wed, Aug 24, 2011 at 11:13:09 +0100:
> > > C. Michael Pilato wrote:
> > >> So back to what I would consider the primary deliverable of interest 
> > >> here:
> > >> avoiding one's own accidental commits.  I'm leaning toward [...]  A
> > >> special changelist honored by our libsvn_client code which does what 
> > >> we're
> > >> talking about here, shows up in 'svn status' like the others do, requires
> > >> very little additional infrastructure, for which state changes are not
> > >> versioned operations (such as they would be with the commits of the 
> > >> addition
> > >> and removal of an svn:hold property), etc.
> 
> I like the sound of this, too, as the local-only part of the solution.
> See below for the centralized part of the solution.
> 
> The set of changelists to use is already passed into the libsvn_client
> API from the client.  Pretty much all we need is a way to specify sets
> of changelists more flexibly.  For the main functionality, the 'commit'
> subcommand would specify "select everything except changelist
> 'svn:ignore-on-commit'" unless overridden.  That would make the file be

Does this require negative changelists?  Currently changelists are
'select only members of this changelist', but you're proposing 'select except
members of this changelist'.

> ignored on commit but otherwise not special (so it would show up in
> diff, etc.).
> 
> And we could define a changelist 'svn:ignore-local-mods' that is ignored
> in all operations that would normally see the local mods - diff, status,
> copy, export, and even cat.  Some of those operations might need to be
> extended to honour changelists if they don't already.  For these
> subcommands the client might specify "all except changelists
> svn:ignore-on-commit and svn:ignore-local-mods", unless overridden, for
> example.

Re: rc1 is DOA. What now?

[Hyrum K Wright]

On Wed, Aug 24, 2011 at 6:07 AM, Julian Foad  wrote:
> On Tue, 2011-08-23, Hyrum K Wright wrote:
>> At this point, I'm ready to run with the consensus, whatever that is.
>
> Having read the discussion elsethread, I now consider this a blocker and
> that also seems to be the consensus.  So we can't release 1.7.0 with
> this bug; it has to be fixed.  That in turn means the supposed 'RC1' is
> no longer an RC at all.  If the bug were found after RC release, the
> process would be different, but we have to draw the line somewhere and
> the moment of release is the obvious place to draw it.
>
> Fix it ASAP and release an RC that we believe is a true candidate at the
> moment of release.
>
> I think we handled this the right way.  Although some of us wanted the
> RC to go ahead with the known bug, because we were not convinced it's
> serious enough, a developer's veto means it's not an RC.  We must
> resolve that one way or the other before moving on, even if we don't
> like the delay.

So the grander feeling seems to be: scuttle rc1 (which already has the
votes for release) and reroll an rc2.  The fix for the 'upgrade with
lock' issue is already on 1.7.x, so we can do this pretty much
whenever we'd like.  I'm inclined to do it tomorrow, following the
normal pattern.

-Hyrum


-- 

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/

Re: rc1 is DOA. What now?

[Hyrum K Wright]

On Wed, Aug 24, 2011 at 4:26 AM, Ivan Zhakov  wrote:
> On Wed, Aug 24, 2011 at 12:38, Bert Huijben  wrote:
>>
>>
>>> -Original Message-
>>> From: Stefan Sperling [mailto:s...@elego.de]
>>> Sent: woensdag 24 augustus 2011 9:50
>>> To: Markus Schaber
>>> Cc: dev@subversion.apache.org
>>> Subject: Re: rc1 is DOA. What now?
>>>
>>> On Wed, Aug 24, 2011 at 08:46:17AM +0200, Markus Schaber wrote:
>>> > To support this unlocking, it would additionally force our software to
>>> > carry both SVN 1.6 and SVN 1.7 libraries at the same time.
>>>
>>> If 1.7.0 was released with this upgrade bug, you would simply have to
>>> wait for a 1.7.x patch release which fixes the bug before upgrading
>>> from 1.6.x.
>>>
>>> This is basically just like any other show stopper you might find
>>> during the upgrade to 1.7. Except that you already know about it now :)
>>>
>>> But I understand your complaints and agree that the problem needs
>>> to be fixed in 1.7.x eventually.
>>
>> * The average TortoiseSVN user in a corporate environment can't
>> upgrade/downgrade its own installation as that as managed via automated
>> distribution.
>> * TortoiseSVN versions can't be installed side by side.
>> (The same problem applies to big multi user installations on shared linux
>> installations using plain svn)
>>
>> How would you answer an e-mail from your sysadmin that tonight before you go
>> home you have to remove all locks from all your working copies because
>> otherwise tomorrow your working copies are broken?
>> (Assuming you have over 40 independent working copies, not counting possible
>> directory externals, like I had when I worked at TCG)
>>
>>
>> I call this a show stopper; and as I suggested before suggesting these users
>> to wait until 1.7.1 is the same as calling this a show stopper.
>> And it also breaks the perfect stability track record we had with a
>> known-in-advance broken release.
>>
>> In my opinion this issue must be fixed by 1.7.0.
>>
> I fully agree with Bert: this upgrade bug is show stopper for 1.7.0. I
> do not see the problem with restarting soak period because we found
> bugs: this is purpose soak period and stabilization to release
> software without known important issues.

To be clear: this type of bug would not have restarted the 4-week soak
if we'd already been in it.  It is well-understood and the fix is
well-scoped.  While I don't claim it has been tested exhaustively,
restarting the soak is reserved for high-impact fixes which require a
large degree of community testing.

-Hyrum



-- 

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/

RE: Proxy authentication with Negotiate uses wrong host

[Greg Hudson]

On Wed, 2011-08-24 at 05:52 -0400, Bert Huijben wrote:
> Then somebody added Kerberos support to neon, but the api wasn't
> updated to allow different behavior for the specific implementations.

Kerberos via HTTP negotiate is also insecure when not used over HTTPS.
In HTTP negotiate, the GSSAPI mechanism (Kerberos) isn't used to protect
the data stream, only to authenticate.  So you still need a secure
channel.

(Also, negotiate auth does no channel binding, which means Kerberos
provides no additional protection against MITM attacks on the TLS
channel.  That just means it's still important for the client to verify
the server cert.  I've heard that Microsoft has some extensions to RFC
4559 to do channel binding, but I don't know any details and Neon almost
certainly doesn't have any support for it.)

Re: rc1 is DOA. What now?

[Julian Foad]

On Tue, 2011-08-23, Hyrum K Wright wrote:
> At this point, I'm ready to run with the consensus, whatever that is.

Having read the discussion elsethread, I now consider this a blocker and
that also seems to be the consensus.  So we can't release 1.7.0 with
this bug; it has to be fixed.  That in turn means the supposed 'RC1' is
no longer an RC at all.  If the bug were found after RC release, the
process would be different, but we have to draw the line somewhere and
the moment of release is the obvious place to draw it.

Fix it ASAP and release an RC that we believe is a true candidate at the
moment of release.

I think we handled this the right way.  Although some of us wanted the
RC to go ahead with the known bug, because we were not convinced it's
serious enough, a developer's veto means it's not an RC.  We must
resolve that one way or the other before moving on, even if we don't
like the delay.

- Julian

Re: dump svn:hold, long live file externals?? (and discussing recursive hold) -- was: bring on your concerns about svn:hold, please

[Julian Foad]

> > C. Michael Pilato wrote:
> >> Neels J Hofmeyr wrote:
> >>> Julian Foad wrote:
>    Use case (2) - Eclipse folder, from issue #3028
> 
>    "For example we have a complete Eclipse instance in our svn
>    repository and we want to ignore every change in its directory
>    and below. [...]"
> >>>
> >>> That's quite a pickle. I'm not intending to make holding stuff recursive,
> >>> because then we'd have to check every commit target up into its ancestors,
> >>> possibly even checking if the *repos* has a hold set on an ancestor. Ugh.
[...]
> >>> And, my goodness, it *is* *already* possible to create a global hold on a
> >>> file using file externals. [...]

+1 on the idea of building a new feature on top of an existing
infrastructure.  It reduces the cognitive load on the user.  We need to
keep in mind that many users don't want or need to learn all about every
feature of Subversion.  If a new feature can be described in two
sentences in terms of another feature, that's a *huge* win.

But ...

> >> Oh, dude.  You're talking now about hacks based on hacks, here.  It makes 
> >> me
> >> hurt.  :-)

... right, -0.9 on trying to use the externals code as such an
infrastructure, in its current state.

[...]
> >> So back to what I would consider the primary deliverable of interest here:
> >> avoiding one's own accidental commits.  I'm leaning toward [...]  A
> >> special changelist honored by our libsvn_client code which does what we're
> >> talking about here, shows up in 'svn status' like the others do, requires
> >> very little additional infrastructure, for which state changes are not
> >> versioned operations (such as they would be with the commits of the 
> >> addition
> >> and removal of an svn:hold property), etc.

I like the sound of this, too, as the local-only part of the solution.
See below for the centralized part of the solution.

The set of changelists to use is already passed into the libsvn_client
API from the client.  Pretty much all we need is a way to specify sets
of changelists more flexibly.  For the main functionality, the 'commit'
subcommand would specify "select everything except changelist
'svn:ignore-on-commit'" unless overridden.  That would make the file be
ignored on commit but otherwise not special (so it would show up in
diff, etc.).

And we could define a changelist 'svn:ignore-local-mods' that is ignored
in all operations that would normally see the local mods - diff, status,
copy, export, and even cat.  Some of those operations might need to be
extended to honour changelists if they don't already.  For these
subcommands the client might specify "all except changelists
svn:ignore-on-commit and svn:ignore-local-mods", unless overridden, for
example.

> Hyrum K Wright wrote:
> > [...] we'd need to support multiple
> > changelists on a single item before going this route.  I wouldn't want
> > a special changelist to exclude standard ones.

I don't see a need for this file to belong to multiple changelists.
Belonging to changelist XXX says "The changes in this file are part of
feature/change/local-experiment XXX".  If changes in this file are to be
ignored, then I don't see it making any sense for this file to belong to
any other changelist, unless and until the user decides that the changes
are not to be ignored.

Most of the time, the user will put the file in changelist
'svn:ignore-on-commit' and no other changes the user is making will want
to include that file.  When the user wants to commit a change to that
file, he/she will either specify "--cl svn:ignore-on-commit" (with or
without other changelist(s), as appropriate) or will move this file into
a different changelist (or none) before commit and move it back into the
special changelist after commit.

Johan Corveleyn wrote:
> IMHO simply using changelists lacks the most important part of the
> feature: the ability to set/configure/annotate this centrally. [...]

Let's not dismiss changelists simply because they don't provide the
*whole* solution.  This may sound like over-complication, but seriously
consider building on top of that.  It's looking like changelists could
provide a decent solution for the local behaviour.  On top of that, we
could provide exactly the 'svn:hold' property mechanism that Neels
already described, but instead of implementing checks for that property
directly, it could be treated as an instruction to the client to put the
file into the 'svn:ignore-on-commit' changelist (detail: if it's not
already in a changelist).

I think it's worth fleshing out a proposal using this approach.

- Julian

RE: Proxy authentication with Negotiate uses wrong host

[Bert Huijben]

> -Original Message-
> From: 1983-01...@gmx.net [mailto:1983-01...@gmx.net]
> Sent: woensdag 24 augustus 2011 10:47
> To: us...@subversion.apache.org
> Subject: Re: Proxy authentication with Negotiate uses wrong host
> 
> > On Wed, Aug 24, 2011 at 09:25:49AM +0200, 1983-01...@gmx.net wrote:
> > > I'll do but why is Negotiate auth activated in session.c if the target
> > host is ssy only? This should be on the user to decide not subversion.
> >
> > I don't know who made this decision and why.
> > Maybe svn blame on that file leads to more info?
> 
> I checked blame already. There was a rather long explanation but still no
> argument to me.

The Subversion parts of this code were written when neon only supported NTLM 
via Negotiate. NTLM is known to be insecure when not used over https.

Then somebody added Kerberos support to neon, but the api wasn't updated to 
allow different behavior for the specific implementations.

As Stefan already noted: this discussion belongs on the neon mailinglist. Once 
neon supports the necessary hooks/apis to enable Negotiate for the secure 
protocols we can enable them in Subversion. 
(Or maybe neon can just enable the safe protocols all the time?)


@serf developers: This should probably be handled in serf too.

Bert 

Re: rc1 is DOA. What now?

[Ivan Zhakov]

On Wed, Aug 24, 2011 at 12:38, Bert Huijben  wrote:
>
>
>> -Original Message-
>> From: Stefan Sperling [mailto:s...@elego.de]
>> Sent: woensdag 24 augustus 2011 9:50
>> To: Markus Schaber
>> Cc: dev@subversion.apache.org
>> Subject: Re: rc1 is DOA. What now?
>>
>> On Wed, Aug 24, 2011 at 08:46:17AM +0200, Markus Schaber wrote:
>> > To support this unlocking, it would additionally force our software to
>> > carry both SVN 1.6 and SVN 1.7 libraries at the same time.
>>
>> If 1.7.0 was released with this upgrade bug, you would simply have to
>> wait for a 1.7.x patch release which fixes the bug before upgrading
>> from 1.6.x.
>>
>> This is basically just like any other show stopper you might find
>> during the upgrade to 1.7. Except that you already know about it now :)
>>
>> But I understand your complaints and agree that the problem needs
>> to be fixed in 1.7.x eventually.
>
> * The average TortoiseSVN user in a corporate environment can't
> upgrade/downgrade its own installation as that as managed via automated
> distribution.
> * TortoiseSVN versions can't be installed side by side.
> (The same problem applies to big multi user installations on shared linux
> installations using plain svn)
>
> How would you answer an e-mail from your sysadmin that tonight before you go
> home you have to remove all locks from all your working copies because
> otherwise tomorrow your working copies are broken?
> (Assuming you have over 40 independent working copies, not counting possible
> directory externals, like I had when I worked at TCG)
>
>
> I call this a show stopper; and as I suggested before suggesting these users
> to wait until 1.7.1 is the same as calling this a show stopper.
> And it also breaks the perfect stability track record we had with a
> known-in-advance broken release.
>
> In my opinion this issue must be fixed by 1.7.0.
>
I fully agree with Bert: this upgrade bug is show stopper for 1.7.0. I
do not see the problem with restarting soak period because we found
bugs: this is purpose soak period and stabilization to release
software without known important issues.

-- 
Ivan Zhakov

RE: rc1 is DOA. What now?

[Bert Huijben]

> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: woensdag 24 augustus 2011 9:50
> To: Markus Schaber
> Cc: dev@subversion.apache.org
> Subject: Re: rc1 is DOA. What now?
> 
> On Wed, Aug 24, 2011 at 08:46:17AM +0200, Markus Schaber wrote:
> > To support this unlocking, it would additionally force our software to
> > carry both SVN 1.6 and SVN 1.7 libraries at the same time.
> 
> If 1.7.0 was released with this upgrade bug, you would simply have to
> wait for a 1.7.x patch release which fixes the bug before upgrading
> from 1.6.x.
> 
> This is basically just like any other show stopper you might find
> during the upgrade to 1.7. Except that you already know about it now :)
> 
> But I understand your complaints and agree that the problem needs
> to be fixed in 1.7.x eventually.

* The average TortoiseSVN user in a corporate environment can't
upgrade/downgrade its own installation as that as managed via automated
distribution.
* TortoiseSVN versions can't be installed side by side.
(The same problem applies to big multi user installations on shared linux
installations using plain svn)

How would you answer an e-mail from your sysadmin that tonight before you go
home you have to remove all locks from all your working copies because
otherwise tomorrow your working copies are broken?
(Assuming you have over 40 independent working copies, not counting possible
directory externals, like I had when I worked at TCG)


I call this a show stopper; and as I suggested before suggesting these users
to wait until 1.7.1 is the same as calling this a show stopper. 
And it also breaks the perfect stability track record we had with a
known-in-advance broken release.

In my opinion this issue must be fixed by 1.7.0.

I don't care if we release rc1 anyway, reroll that as beta4 today or roll a
rc2 this week or accept this as a low impact fix for 1.7.0 without
restarting the soak. But rolling a known broken 1.7.0 because it is already
late is not good enough. 

Maybe it is for the few developers who build and install their own binaries
side by side, but not for our real users.


Taking a few weeks to discuss this issue before making a decision is not
going to help...
 Ivan and I already described this as a show stopper for our users and I'm
pretty sure Stefan would too.
(As noted by Markus I already have the fix in my daily snapshots which
currently follow 1.7.x)

Bert

Re: rc1 is DOA. What now?

[Stefan Sperling]

On Wed, Aug 24, 2011 at 08:46:17AM +0200, Markus Schaber wrote:
> To support this unlocking, it would additionally force our software to
> carry both SVN 1.6 and SVN 1.7 libraries at the same time.

If 1.7.0 was released with this upgrade bug, you would simply have to
wait for a 1.7.x patch release which fixes the bug before upgrading
from 1.6.x.

This is basically just like any other show stopper you might find
during the upgrade to 1.7. Except that you already know about it now :)

But I understand your complaints and agree that the problem needs
to be fixed in 1.7.x eventually.