Re: SVN

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': Nenhum

Re: RE: Proxy authentication with Negotiate uses wrong host

> 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 negotiat

Re: RE: Proxy authentication with Negotiate uses wrong host

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

SVN

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

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

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-cust

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

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 cha

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

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 fi

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

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.

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

[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 canno

Re: diff --summarize

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 t

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

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 s

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

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

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

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

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

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 > handlin

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

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 t

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

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 cha

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

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

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

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 > e

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

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 w

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

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

Re: diff --summarize

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

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

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 + plaste

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

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

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

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 excl

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

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

Re: rc1 is DOA. What now?

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 g

Re: rc1 is DOA. What now?

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 w

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

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

Re: rc1 is DOA. What now?

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

Re: svn_fs_verify() in 1.7.0

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

Re: rc1 is DOA. What now?

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,

svn_fs_verify() in 1.7.0

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?

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

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

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 midd

RE: rc1 is DOA. What now?

> -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 tha

Re: rc1 is DOA. What now?

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 b

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

[ 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. > >

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

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 i

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

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 fro

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

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 > > >

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

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 --c

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

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 lea

Re: rc1 is DOA. What now?

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'

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

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 libs

Re: rc1 is DOA. What now?

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

Re: rc1 is DOA. What now?

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 >>> Subj

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 mec

Re: rc1 is DOA. What now?

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 tur

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

> > 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

RE: Proxy authentication with Negotiate uses wrong host

> -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

Re: rc1 is DOA. What now?

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

RE: rc1 is DOA. What now?

> -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 unl

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