Looks like it's a known issue, see
3430 @XFail()
3431 @Issue(3814)
3432 def patch_set_prop_no_eol(sbox):
3433 "patch doesn't append newline to properties"
3618 @XFail()
3619 @Issue(3991)
3620 def patch_lacking_trailing_eol(sbox):
3621 "patch file lacking trailing eol"
which are currently the
On Fri, Nov 25, 2011 at 2:38 PM, Ryan Schmidt
wrote:
> On Nov 25, 2011, at 10:06, Jannis wrote:
>
>> 2. And changed the relevant line in DESCRIPTION to:
>>
>> Version: 0.5.0.$LastChangedRevision$
>>
>>
>> This works partially but changes the line in DESCRIPTION to (for example):
>>
>> Version: 0.5
On Nov 25, 2011, at 10:06, Jannis wrote:
> 2. And changed the relevant line in DESCRIPTION to:
>
> Version: 0.5.0.$LastChangedRevision$
>
>
> This works partially but changes the line in DESCRIPTION to (for example):
>
> Version: 0.5.0.$LastChangedRevision: 28 $
>
> I need, however:
>
> Vers
---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
with as much information as possible about what
you were trying to do.
But please first search the mailing list
I just encountered a possible issue with the new 'svn patch' command in
Subversion 1.7.1 (r1186859). When the patchfile includes svn:eol-style
property changes, they do not seem to get applied properly.
An example patchfile is attached. It was generated by doing the
following in some random svn
Dear subversion users,
I am trying to automatically get the actual revision number of my subversion
repository into a text file inside the subversion project.
More precisely, I am using subversion to keep track of the changes I do to the
code of several R packages. These packages contain a fi
On Fri, Nov 25, 2011 at 3:57 AM, Cooke, Mark wrote:
> [Please reply in-line, it makes it easier to see the full context...]
>> > Dear Sir,
>> >
>> > We are in the process of selecting SVN system in our company,
>> > could you please clarify following points.
>> >
>> > 1. Restricting branching act
On Nov 25, 2011, at 2:02 PM, Stefan Sperling wrote:
> On Fri, Nov 25, 2011 at 01:38:44PM +0100, Vyacheslav Zholudev wrote:
>> I guess "badness" can happen only when accessing repositories locally (not
>> via svn:// or http(s)://) with patched and not patched SVN.
>> But usually only one version
On Fri, Nov 25, 2011 at 01:38:44PM +0100, Vyacheslav Zholudev wrote:
> I guess "badness" can happen only when accessing repositories locally (not
> via svn:// or http(s)://) with patched and not patched SVN.
> But usually only one version of SVN is installed on the server side, so that
> should
I guess "badness" can happen only when accessing repositories locally (not via
svn:// or http(s)://) with patched and not patched SVN.
But usually only one version of SVN is installed on the server side, so that
should not be a big problem.
However, it's a nice exercise to check.
Vyacheslav
To clarify, the issues I was concerned about weren't with tree changes
(the level of the code dealing with content reps isn't aware of those),
but with creating/accessing a single repository sometimes via
unmodified svn 1.7.1 libraries and sometimes via forward-delta-patched
libraries.
The part I
Thanks, I studied math not in English, that's why I didn't know :)
I made a simple tests and it seems to work nicely. However, I'm not sure
whether it will work with more complicated cases like copying, deleting, etc.
Vyacheslav
On Nov 25, 2011, at 1:15 PM, Daniel Shahaf wrote:
> "left as an
"left as an exercise for the reader" --- in other words, I was
identifying a potential issue and letting the audience figure out the
solution for themselves. It's a standard idiom in math textbooks...
(and, of course, if you have questions about that interoperability
issue, feel free to raise the
Thanks, Daniel. That's the pointer I needed.
However, I didn't understand what LAAEFTR means.
Vyacheslav
On Nov 25, 2011, at 12:17 PM, Daniel Shahaf wrote:
> Change SVN_FS_BASE__MIN_FORWARD_DELTAS_FORMAT to be larger than
> SVN_FS_BASE__FORMAT_NUMBER.
>
> Whether repositories created by an svn
Change SVN_FS_BASE__MIN_FORWARD_DELTAS_FORMAT to be larger than
SVN_FS_BASE__FORMAT_NUMBER.
Whether repositories created by an svn patched in this way will be
interoperable with repositories created by an unpatched svn is
LAAEFTR'd. I'd be cautious and change db/fs-type or db/format.
Vyacheslav
Hi Daniel,
would it be easy to change the code (I want to do it for my experiments) so
that the HEAD (youngest) revisions are stored as fulltexts? Or is it something
that was not foreseen by design to easily switch between approaches of
representing history information?
Thanks,
Vyacheslav
On
Vyacheslav Zholudev wrote on Fri, Nov 25, 2011 at 11:13:00 +0100:
>
> > Old BDB-backed repositories stored the older revision as fulltext and
> > newer revisions as deltas.
>
> Really?
It seems that I should have swapped "older" and "newer" in the quoted
sentence. Thanks for catching that.
>
> Old BDB-backed repositories stored the older revision as fulltext and
> newer revisions as deltas.
Really? Here is a quotation from SVN 1.4.6 libsvn_fs_base/note/structure:
"At present, Subversion generally stores
the youngest strings in "fulltext" form, and older strings as "delta"s
against
[Please reply in-line, it makes it easier to see the full context...]
> -Original Message-
> From: Jerryleen S [mailto:jerrylee...@prdcinfotech.com]
> Sent: 25 November 2011 09:43
> To: Cooke, Mark; users@subversion.apache.org
> Cc: channaveeraswamy
> Subject: RE: Queries about SVN (Secu
Dear Mark,
Thanks for prompt reply, is it possible to give hook script for first 2
queries as I have done exhaustive search in search forums but haven't
found hook script to do the following action
> 1. Restricting branching activity based on roles specified.
>That is denying branch functi
20 matches
Mail list logo
