Hi SVN users/developers,
Is there a limitation in size on the property value that can be
set? Any scalability traps to be aware of (i.e. non-linear
increase in time due to increase in size of the property value)?
I tried a 4Mb property, seems to work fine...
Thanks,
Alexey.
On 12.08.2014 03:31, Alexey Neyman wrote:
>
> Hi SVN users/developers,
>
>
>
> Is there a limitation in size on the property value that can be set?
> Any scalability traps to be aware of (i.e. non-linear increase in time
> due to increase in size of the property value)? I tried a 4Mb
> property,
On Tuesday, August 12, 2014 06:59:20 AM Branko Čibej wrote:
> On 12.08.2014 03:31, Alexey Neyman wrote:
> > Hi SVN users/developers,
> >
> > Is there a limitation in size on the property value that can be set?
> > Any scalability traps to be aware of (i.e. non-linear increase in time
> > due to in
On 12.08.2014 07:16, Alexey Neyman wrote:
>
> On Tuesday, August 12, 2014 06:59:20 AM Branko Čibej wrote:
>
> > On 12.08.2014 03:31, Alexey Neyman wrote:
>
> > > Hi SVN users/developers,
>
> > >
>
> > > Is there a limitation in size on the property value that can be set?
>
> > > Any scalability tra
On Tuesday, August 12, 2014 07:44:03 AM Branko Čibej wrote:
> On 12.08.2014 07:16, Alexey Neyman wrote:
> > On Tuesday, August 12, 2014 06:59:20 AM Branko Čibej wrote:
> > > On 12.08.2014 03:31, Alexey Neyman wrote:
> > > > Hi SVN users/developers,
> > > >
> > > >
> > > >
> > > > Is there a limi
On 12.08.2014 08:17, Alexey Neyman wrote:
>
> On Tuesday, August 12, 2014 07:44:03 AM Branko Čibej wrote:
>
>
> > I'm still not sure what you're trying to achieve, though. "Communication
>
> > between pre- and post-commit hooks" doesn't describe the problem, it
>
> > describes a solution, and there
On Tuesday, August 12, 2014 08:33:06 AM Branko Čibej wrote:
> On 12.08.2014 08:17, Alexey Neyman wrote:
> > On Tuesday, August 12, 2014 07:44:03 AM Branko Čibej wrote:
> > > I'm still not sure what you're trying to achieve, though. "Communication
> > >
> > > between pre- and post-commit hooks" doe
On 12.08.2014 09:26, Alexey Neyman wrote:
>
> On Tuesday, August 12, 2014 08:33:06 AM Branko Čibej wrote:
>
>
> > So why do you need the last-changed revision of the project directory
>
> > stored in the header file? Are you distributing sources directly from
>
> > the repository, or are you using
On Tuesday, August 12, 2014 09:43:39 AM Branko Čibej wrote:
> On 12.08.2014 09:26, Alexey Neyman wrote:
> > On Tuesday, August 12, 2014 08:33:06 AM Branko Čibej wrote:
> > > So why do you need the last-changed revision of the project directory
> > > stored in the header file? Are you distributing s
On 12.08.2014 18:09, Alexey Neyman wrote:
>
> Speaking of 'wish' items:
>
>
>
> - How hard would be to implement client-side hooks? I know TortoiseSVN
> has them, but they're local - and to be really useful, they need to be
> propagated from the repository. And it would be nice to have them
> sup
I intended to reply to your other thread given roughly the same svnversion
advice that Branko has already given you.
On 8/12/14 9:09 AM, Alexey Neyman wrote:
> 1. svnversion reports the revision of the check-out, not the revision of the
> last modification.
Use one of the alternatives that behave
On 8/12/14 9:31 AM, Branko Čibej wrote:
> For a start, this would require a major change in the wire protocol, where the
> server would, as a response to a successful commit, report any additional
> "magic" changes to the client. The problem with this is that it is error
> prone;
> the response ma
On Tuesday, August 12, 2014 11:49:39 am Ben Reser wrote:
> I intended to reply to your other thread given roughly the same svnversion
> advice that Branko has already given you.
>
> On 8/12/14 9:09 AM, Alexey Neyman wrote:
> > 1. svnversion reports the revision of the check-out, not the revision o
On 8/12/14 12:26 PM, Alexey Neyman wrote:
> Please consider these questions closed. For the 'last changed rev/date' I'll
> modify the 'svnversion -c' and will submit a patch to support reporting the
> dates as well (hopefully, it can then be applied to 1.8.x branch as well) and
> for the caching
On Tuesday, August 12, 2014 11:53:09 AM Ben Reser wrote:
> On 8/12/14 9:31 AM, Branko Čibej wrote:
> > For a start, this would require a major change in the wire protocol, where
> > the server would, as a response to a successful commit, report any
> > additional "magic" changes to the client. The
On 8/12/14 7:02 PM, Alexey Neyman wrote:
> Isn't that the same kind of change that happened with version 1.5 and
> mergeinfo? If one wanted to use mergeinfo, one had to have 1.5+ clients. A
> capability reporting was added, and a server can check that only
> mergeinfo-capable clients can start a co
On Tuesday, August 12, 2014 10:18:48 PM Ben Reser wrote:
> On 8/12/14 7:02 PM, Alexey Neyman wrote:
> > Isn't that the same kind of change that happened with version 1.5 and
> > mergeinfo? If one wanted to use mergeinfo, one had to have 1.5+ clients. A
> > capability reporting was added, and a serv
Branko Čibej writes:
> For a start, this would require a major change in the wire protocol,
> where the server would, as a response to a successful commit, report any
> additional "magic" changes to the client. The problem with this is that
> it is error prone; the response may never arrive, for
18 matches
Mail list logo
