On Wed, Nov 09, 2011 at 06:50:35PM -0600, Hyrum K Wright wrote:
> Somebody approached me a few minutes ago at ApacheCon and posed the
> following question:
> "The username on my local box is different than my username on the server,
> and I don't want to cache passwords. How can I cache just the u
On Tue, Nov 8, 2011 at 6:22 AM, Julian Foad wrote:
> Hi Bill.
>
> Let me see if I understand.
>
> You describe a procedure for converting a set of parallel renames into an
> equivalent incremental sequence of renames. That is, the input is a list of
> N independent renames, where each "rename[i
On 11/08/2011 08:55 AM, Markus Schaber wrote:
Hi,
Von: Miha Vitorovic [mailto:miha.vitoro...@gmail.com]
On 7.11.2011 16:08, Neels J Hofmeyr wrote:
Can you argue up a case where one would want a non-revision-pegged
external excluded from commit? I'm reluctant to take simply previous
externals
On 11/10/2011 10:29 AM, Neels J Hofmeyr wrote:
> It seems to me that excluding only those externals (dir & file) that are
> fixed to a specific revision is the best solution. My only worry are all
> those users out there expecting dir externals to be excluded always.
>
> That's why I'm asking: if
On 11/10/2011 04:40 PM, C. Michael Pilato wrote:
On 11/10/2011 10:29 AM, Neels J Hofmeyr wrote:
It seems to me that excluding only those externals (dir& file) that are
fixed to a specific revision is the best solution. My only worry are all
those users out there expecting dir externals to be ex
2 3 4 5
BranchA--o-
\
\ "A:2"
BranchB-o---o--
\
\ "A:2 B:3-4"
BranchCo---
Philip and I were prompted by a c
Julian Foad writes:
> 2 3 4 5
> BranchA--o-
> \
>\ "A:2"
> BranchB-o---o--
> \
> \ "A:2 B:3-4"
> BranchCo
Julian Foad wrote on Thu, Nov 10, 2011 at 17:13:41 +:
> 2 3 4 5
> BranchA--o-
> \
>\ "A:2"
> BranchB-o---o--
> \
> \ "A:2 B:3-4"
> BranchC-
On Thu, Nov 10, 2011 at 12:13 PM, Julian Foad wrote:
> 2 3 4 5
> BranchA--o-
> \
>\ "A:2"
> BranchB-o---o--
> \
> \ "A:2 B:3-4"
> BranchC-
Yes this feature is used by some enterprises (what percentage I would
have no idea, but it is always seen as a positive in training sessions).
I don't think we had the time or interest to put in extra functionality
that didn't come from community requirements.
Again, I don't think this list is
On 11/10/2011 11:15 AM, Neels J Hofmeyr wrote:
> On 11/10/2011 04:40 PM, C. Michael Pilato wrote:
>> On 11/10/2011 10:29 AM, Neels J Hofmeyr wrote:
>>> It seems to me that excluding only those externals (dir& file) that are
>>> fixed to a specific revision is the best solution. My only worry are a
Mark Phippard writes:
> On Thu, Nov 10, 2011 at 12:13 PM, Julian Foad wrote:
>
>> 2 3 4 5
>> BranchA--o-
>> \
>>\ "A:2"
>> BranchB-o---o--
>> \
>>
Jonathan Nieder writes:
> [[[
> * Makefile.in (check): Set LD_LIBRARY_PATH so the just-built versions
> of auth plugins are used when running the test suite. Otherwise,
> auth-test can easily fail because some auth provider it expects to
> find is missing.
> ]]]
I committed this, wi
On Thu, Nov 10, 2011 at 12:13 PM, Julian Foad wrote:
> 2 3 4 5
> BranchA--o-
> \
> \ "A:2"
> BranchB-o---o--
> \
> \ "A:2 B:3-4"
> BranchC-
On Thu, Nov 10, 2011 at 1:13 PM, Philip Martin
wrote:
> > This statement is not true. You can still merge BranchA to BranchC in
> the
> > above scenario. SVN does not have any limits on where you can merge from
> > and to.
>
> Yes, Subversion allows one do it, but it doesn't work reliably. It's
Paul Burba writes:
> Does this answer your question at all (or did I answer a different
> question ;-)
That's the cyclic merge again. Storing the transitive mergeinfo makes
cyclic merge work in some circumstances but not in others. What we are
trying to determine is whether that is the only us
On 11/10/2011 07:10 PM, C. Michael Pilato wrote:
As a community, we need to decide how we will handle file externals in
general. Their clever implementation invites inconsistency.
I think there is general agreement (to the degree of common sense?) that
file and dir externals should behave the
On 11/10/2011 03:34 PM, Neels J Hofmeyr wrote:
> It was suggested to extend the svn:externals syntax, adding a flag that
> marks externals that should behave differently. By now this seems to me to
> be the best way out. What would that look like?
The next change we make to the externals syntax ne
On 11/10/2011 09:39 PM, C. Michael Pilato wrote:
The next change we make to the externals syntax needs to be to add an
explicit "#format = 3" header to it so we can stop trying to deduce the
format the user intended!
now that's cumbersome. a footer would be much nicer. ;)
~Neels
[Hyrum K Wright]
> "The username on my local box is different than my username on the server,
> and I don't want to cache passwords. How can I cache just the username?"
Aside from the real answer Stefan gave, with svn+ssh you can specify
user@server in the URI, and that is retained. Alternative
On 10.11.2011 16:21, Neels J Hofmeyr wrote:
On 11/07/2011 07:14 PM, Miha Vitorovic wrote:
On 7.11.2011 16:08, Neels J Hofmeyr wrote:
Can you argue up a case where one would want a non-revision-pegged
external
excluded from commit? I'm reluctant to take simply previous externals
behavior as arg
On Thu, Nov 10, 2011 at 3:13 PM, Peter Samuelson wrote:
>
> [Hyrum K Wright]
> > "The username on my local box is different than my username on the
> server,
> > and I don't want to cache passwords. How can I cache just the username?"
>
> Aside from the real answer Stefan gave, with svn+ssh you
On Thu, Nov 10, 2011 at 4:40 PM, C. Michael Pilato wrote:
> On 11/10/2011 10:29 AM, Neels J Hofmeyr wrote:
>> It seems to me that excluding only those externals (dir & file) that are
>> fixed to a specific revision is the best solution. My only worry are all
>> those users out there expecting dir
Philip Martin wrote:
> I committed this, with a small tweak to move where the variables are
> set.
Thanks, Philip. I like the tweak.
24 matches
Mail list logo
