On Wed, Nov 24, 2010 at 3:43 AM, Gavin Beau Baumanis
gav...@thespidernet.com wrote:
Hi Daniel (T),
Since in your earlier post you mentioned that you didn't mind a friendly
reminder...
I thought I would return this thread to the top of the list - Just i case
you had missed Daniel (Shahaf)
The only difference between translate_newline() and translate_newline_alt()
is the lines of code from here to the end of the function. I think you
could keep translate_newline() as is, and just move these checks elsewhere
(to a new function or to the caller; I haven't thought about this in
I am having trouble building trunk. The make process always fails when
linking libsvn_repos-1:
cd subversion/libsvn_repos /usr/share/apr-1.0/build/libtool
--tag=CC --silent --mode=link gcc -Wno-system-headers
-Wold-style-definition -Wdeclaration-after-statement -Wpointer-arith
-Wwrite-strings
On Sun, Nov 7, 2010 at 8:01 AM, Stefan Sperling s...@elego.de wrote:
On Sun, Nov 07, 2010 at 07:56:51AM -0800, Daniel Trebbien wrote:
I am having trouble building trunk. The make process always fails when
linking libsvn_repos-1:
Looks like the linker or libtool is picking up conflicting
Weird. It seems that `subversion/libsvn_repos/load-fs-vtable.c` was
the only C file in `subversion/libsvn_repos` that wasn't being
compiled. So, I modified the CC line that compiled
`subversion/libsvn_repos/log.c` to instead compile
`subversion/libsvn_repos/load-fs-vtable.c` and manually added
On Sun, Nov 7, 2010 at 12:04 PM, Daniel Trebbien dtrebb...@gmail.com wrote:
Weird. It seems that `subversion/libsvn_repos/load-fs-vtable.c` was
the only C file in `subversion/libsvn_repos` that wasn't being
compiled. So, I modified the CC line that compiled
`subversion/libsvn_repos/log.c
Hi Daniel,
Thank you for your feedback. I have attached a new patch and log
message that addresses the points that you have mentioned.
If we can provide the information cheaply, I see no reason not to let
the APIs provide it. As some of these APIs are already revved for 1.7,
we might as
On Mon, Oct 18, 2010 at 3:05 AM, Gavin Beau Baumanis
gav...@thespidernet.com wrote:
Hi Daniel,
This is just a friendly poke.
Are you happy to have me annoy you every so often - or would just like me
leave it entirely with you ?
Gavin Beau Baumanis
Hi Gavin,
I don't mind at all.
On Fri, Oct 1, 2010 at 3:57 AM, Julian Foad julian.f...@wandisco.com wrote:
Adds a public API function, svn_subst_translate_string2(), an extension of
svn_subst_translate_string(), that has two, additional output parameters for
determining whether re-encoding and/or line ending translation were
On Fri, Oct 1, 2010 at 4:14 AM, Bert Huijben b...@qqmail.nl wrote:
@@ -650,7 +651,13 @@ translate_newline(const char *eol_str,
*src_format_len = newline_len;
}
/* Translate the newline */
- return translate_write(dst, eol_str, eol_str_len);
+ svn_error_t *err =
Following Daniel Shahaf's suggestion of splitting the allow svnsync
to translate non-UTF-8 log messages to UTF-8 work into two patches, I
have revised my changes, prepared one of the two patches, and have
attached the one patch and suggested log message to this e-mail.
Adds a public API function,
...@thespidernet.com wrote:
Hi Daniel (Trebbien),
Just thought I would ask for an update, please.
I still have you on my watch - list - so there is no rush - just making
sure for my own sanity that I haven't missed an email / thread about your
patch submission.
Gavin Beau Baumanis
On Sun, Sep 19, 2010 at 9:39 PM, Daniel Shahaf d...@daniel.shahaf.name wrote:
* subversion/include/svn_subst.h
Added documentation of the new public API function
svn_subst_translate_string2().
Should use this syntax:
* subversion/include/svn_subst.h
(svn_subst_translate_string2): New
Daniel Trebbien dtrebbien at gmail.com writes:
Yes, I did copy-and-paste. I see your point, though, and I am going to
correct this by adding another `static` function that both will call.
Never mind the talk of a new static function. `svn_subst_translate_string`
should
of course call
Hyrum K. Wright hyrum_wright at mail.utexas.edu writes:
Thanks. Though I'll probably wait a day or two, to let any dissenters
make themselves known. :)
-1/2. There are parts of your idea that I like, such as linking to common
documentation, enumerating all of the errors that can be returned,
Looking through the source code for `svn_subst_translate_string` in
`subversion/libsvn_subr/subst.c`, it seems odd to me that the `repair`
parameter to the call to `svn_subst_translate_cstring2` (for
translating the line endings) is `FALSE`. `FALSE` means that if the
line endings are inconsistent,
On Sun, Sep 12, 2010 at 1:49 PM, Daniel Shahaf d...@daniel.shahaf.name wrote:
When I was working on my changes, I was looking for a to UTF-8
function that would return whether it actually re-encoded the input
string, but did not find one. The re-encoding function that I used,
[[[
Add a command line option to the svnsync init, sync, and copy-revprops
subcommands (--source-encoding) that allows the user to specify the
character encoding of translatable properties from the source
repository. This is needed to allow svnsync to import some older
Subversion repositories that
On Fri, Sep 10, 2010 at 9:16 AM, Daniel Shahaf d...@daniel.shahaf.name wrote:
The patch didn't make it to the list (only to my personal copy), could
you please re-send with the patch in text/plain MIME type?
Hmmm. I wonder if adding a .txt extension will work...
Index: subversion/svnsync/sync.h
* subversion/svnsync/main.c
(svnsync_cmd_table): Added svnsync_opt_source_encoding to the list
of acceptable options for the init, sync, and copy-revprops
subcommands.
Missing indentation on the non-first lines. Should be in one of these forms:
[[[
* subversion/svnsync/main.c
.
(more below)
Daniel Trebbien wrote on Wed, Sep 08, 2010 at 18:58:06 -0700:
On Wed, Sep 8, 2010 at 4:39 PM, Daniel Trebbien dtrebb...@gmail.com wrote:
I think that a call to `svn_subst_translate_string`
(http://svn.collab.net/svn-doxygen/svn__subst_8h.html#a29) needs to be
added
21 matches
Mail list logo
