I think you're misunderstanding me. I noted this in the conversation above:
"One conflict option that's *not done yet* is one that merges a textual
change from a path ^/trunk/B to a path ^/branch/A, after a move A -> B on
trunk. I don't consider this a release blocker. We can always add this
option
Yup. I'm able to go down a rabbit hole on things, though. I've just spent
an hour trying to find a docker image to start with so that I was able to
ship something that's easily run as an an example for this group. Who knew
there's a *few thousand* ways of configuring Apache in docker images, heh?
On Thu, Nov 23, 2017 at 03:53:02PM -0500, Paul Hammant wrote:
> >
> >
> > > Is that a regression versus v1.9 and before?
> >
> > Far from it.
> > This discussion is about the new conflict resovler added in 1.10.
> >
> > We can and always could perform such merges by manually specifying
> > the path
>
>
> > Is that a regression versus v1.9 and before?
>
> Far from it.
> This discussion is about the new conflict resovler added in 1.10.
>
> We can and always could perform such merges by manually specifying
> the paths, i.e. running a merge from ^/trunk/B to branch/A.
>
> The goal of the resolver
Yes, I was also about to suggest mod_rewrite. Should be possible to match on
your secret hidden filename and return content from a “shadow” directory
structure that only contains those files.
You could generate those files in the shadow structure on the post-commit
event.
I have rewrites wit
On Thu, Nov 23, 2017 at 10:55:02AM -0500, Paul Hammant wrote:
> >
> >
> > One conflict option that's not done yet is one that merges a textual change
> > from a path ^/trunk/B to a path ^/branch/A, after a move A -> B on trunk.
> > I don't consider this a release blocker. We can always add this opt
"Two docroots" might be what I'm looking for: http://madbean.com/2007/two-
docroots/
The author, Matt Quail, has been Jira lead for a decade, I think.
Johan Corveleyn wrote:
It seems that's not possible currently (I've checked with some other
devs on #svn-dev on freenode IRC).
Marcin, please do join us on the IRC channel if you want to have a 'high
bandwidth' chat about this -- maybe more ideas will come from chatting.
(Nowadays I recommen
On Thu, Nov 23, 2017 at 4:12 PM, wrote:
>
> Hi Johan,
>
> I didn't know about that setting thanks for the pointer.
>
> However It looks like it's a way to set an alternative path to the hooks-env
> file. Which is global per repository. What we're trying to solve is to have a
> dynamic env that w
OK, so most of ye know I am on this quest.
*Context*: I've a working merkle-ish client tracking changes in a Svn
server over DAV, and noting when files directories change and replicating
that change on the client side. For files it gets the SHA1 for the file,
stores it, and updates local file copi
>
>
> One conflict option that's not done yet is one that merges a textual change
> from a path ^/trunk/B to a path ^/branch/A, after a move A -> B on trunk.
> I don't consider this a release blocker. We can always add this option in
> a patch release.
>
>
Is that a regression versus v1.9 and befor
Hi Johan,
I didn't know about that setting thanks for the pointer.
However It looks like it's a way to set an alternative path to the hooks-env
file. Which is global per repository. What we're trying to solve is to have a
dynamic env that would inherit some variables per request. e.g IP address o
Stefan Sperling wrote on Wed, Nov 22, 2017 at 13:41:11 +0100:
> But I probably won't have time to help with preparations.
Likewise.
Julian Foad wrote on Wed, Nov 22, 2017 at 17:17:34 +0100:
> Re. shelving...
>
> Branko Čibej wrote:
> > Unless you're absolutely certain that the format and semantics of the
> > CLI commands won't change, I do suggest adding an "experimental" warning
> > to the help text.
>
> Done. Thanks.
I don
On Wed, Nov 22, 2017 at 1:36 PM, wrote:
> Hi,
>
> We're trying to build a generic integration system for RhodeCode that would
> also support Subversion. The problem we're now having is how to transmit
> some data during e.g commit operation from our system into running hooks.
> Our idea now is to
On 22.11.2017 22:08, Evgeny Kotkov wrote:
Stefan Sperling writes:
However, if rep-sharing is enabled, svn_fs_props_changed() does not work
as advertised because properties do not carry a SHA1 checksum with a
"uniquifier" which identifies the transaction they were created in.
The uniquifier is
Hi Julian,
> This bug occurred because the "%ld" format and/or the 'long' data type
were 32-bit. This is indeed the case:
> On 64-bit Windows, 'long' is a 32-bit type (and 'long long' is 64-bit; on
most other platforms both are 64-bit.)
Ok, that explains it. I did not know that 'long' is 32 bits
Ronald Taneza wrote:
Hi Julian,
Thank you for your quick response and patch. I hope that this is fixed
in the next 1.8.x release and that CollabNet will also release an update
to Subversion Edge.
It should be.
I'm still not so clear how this is exactly a problem with svnrdump
1.8.19 (from
Hi Julian,
Thank you for your quick response and patch. I hope that this is fixed in
the next 1.8.x release and that CollabNet will also release an update to
Subversion Edge.
I'm still not so clear how this is exactly a problem with svnrdump 1.8.19
(from Subversion Edge). This is my first time br
Julian Foad wrote:
Evgeny Kotkov wrote:
I think that using APR_SIZE_T_FMT would still lead to the same issue with
large file sizes in the 32-bit environment (where size_t is also 32 bit).
Perhaps, the code should be using APR_OFF_T_FMT as the format specifier?
(The apr_file_info_t.size value i
20 matches
Mail list logo
