Re: How to open specified inside .svn
On 02.03.2019 15:18, wuzhouhui wrote: >> On Mar 2, 2019, at 10:09 PM, wuzhouhui wrote: >> >>> On Mar 2, 2019, at 9:41 PM, Branko Čibej wrote: >>> >>> On 02.03.2019 05:29, wuzhouhui wrote: > On Mar 2, 2019, at 8:21 AM, Daniel Shahaf wrote: > > wuzhouhui wrote on Fri, Mar 01, 2019 at 17:46:55 +0800: >>> -Original Messages- >>> From: "Branko Čibej" >>> Sent Time: 2019-03-01 17:16:40 (Friday) >>> To: users@subversion.apache.org >>> Cc: >>> Subject: Re: How to open specified inside .svn >>> >>> There are no such generic functions. The svn_wc API isn't really meant >>> to be public, so you'll have to write your own access functions. Look at >>> how the svn_client implementations do it, or for example >>> svn_wc__get_pristine_contents_by_checksum in svn_wc_private.h. >> Actually, I'm hacking Subversion client command line tool, so it >> doesn't matter whether the API is public or private. > The difference isn't just visibility. We don't promise compatibility > for private APIs, not even across patch releases in the same minor line > (1.A.x and 1.A.y). Thanks for your reminding. I have implement client side pre-commit hook. The implementation maybe ugly, but it works at least. In case of someone have interests, you can find my customized Subversion in https://github.com/wuzhouhui/subversion. Please forgive me about using Git to version control Subversion :-) >>> >>> Using git is not a problem. Calling it Subversion _is_ a problem. Please >>> rename it to something else. > Ok, I understand your point. The "Subversion" is registered name of Apache, so > I couldn't use this name casually. > > Thanks for your reminding. Actually the possible confusion worries me more than the registered trademark. Thanks for renaming it! -- Brane > >> Calling it Subversion may confusing people (is it your concern?), rename it >> to >> WuSVN. I hope this new name won't introduce any trouble. >> >> Thanks. >> >>> -- Brane
Re: How to open specified inside .svn
> On Mar 2, 2019, at 10:09 PM, wuzhouhui wrote: > >> >> On Mar 2, 2019, at 9:41 PM, Branko Čibej wrote: >> >> On 02.03.2019 05:29, wuzhouhui wrote: On Mar 2, 2019, at 8:21 AM, Daniel Shahaf wrote: wuzhouhui wrote on Fri, Mar 01, 2019 at 17:46:55 +0800: >> -Original Messages- >> From: "Branko Čibej" >> Sent Time: 2019-03-01 17:16:40 (Friday) >> To: users@subversion.apache.org >> Cc: >> Subject: Re: How to open specified inside .svn >> >> There are no such generic functions. The svn_wc API isn't really meant >> to be public, so you'll have to write your own access functions. Look at >> how the svn_client implementations do it, or for example >> svn_wc__get_pristine_contents_by_checksum in svn_wc_private.h. > Actually, I'm hacking Subversion client command line tool, so it > doesn't matter whether the API is public or private. The difference isn't just visibility. We don't promise compatibility for private APIs, not even across patch releases in the same minor line (1.A.x and 1.A.y). >>> Thanks for your reminding. I have implement client side pre-commit hook. >>> The implementation maybe ugly, but it works at least. >>> >>> In case of someone have interests, you can find my customized Subversion >>> in https://github.com/wuzhouhui/subversion. Please forgive me about using >>> Git to version control Subversion :-) >> >> >> Using git is not a problem. Calling it Subversion _is_ a problem. Please >> rename it to something else. Ok, I understand your point. The "Subversion" is registered name of Apache, so I couldn't use this name casually. Thanks for your reminding. > > Calling it Subversion may confusing people (is it your concern?), rename it to > WuSVN. I hope this new name won't introduce any trouble. > > Thanks. > >> >> -- Brane
Re: How to open specified inside .svn
> On Mar 2, 2019, at 9:41 PM, Branko Čibej wrote: > > On 02.03.2019 05:29, wuzhouhui wrote: >>> On Mar 2, 2019, at 8:21 AM, Daniel Shahaf wrote: >>> >>> wuzhouhui wrote on Fri, Mar 01, 2019 at 17:46:55 +0800: > -Original Messages- > From: "Branko Čibej" > Sent Time: 2019-03-01 17:16:40 (Friday) > To: users@subversion.apache.org > Cc: > Subject: Re: How to open specified inside .svn > > There are no such generic functions. The svn_wc API isn't really meant > to be public, so you'll have to write your own access functions. Look at > how the svn_client implementations do it, or for example > svn_wc__get_pristine_contents_by_checksum in svn_wc_private.h. Actually, I'm hacking Subversion client command line tool, so it doesn't matter whether the API is public or private. >>> The difference isn't just visibility. We don't promise compatibility >>> for private APIs, not even across patch releases in the same minor line >>> (1.A.x and 1.A.y). >> Thanks for your reminding. I have implement client side pre-commit hook. >> The implementation maybe ugly, but it works at least. >> >> In case of someone have interests, you can find my customized Subversion >> in https://github.com/wuzhouhui/subversion. Please forgive me about using >> Git to version control Subversion :-) > > > Using git is not a problem. Calling it Subversion _is_ a problem. Please > rename it to something else. Calling it Subversion may confusing people (is it your concern?), rename it to WuSVN. I hope this new name won't introduce any trouble. Thanks. > > -- Brane
Re: How to open specified inside .svn
On 02.03.2019 05:29, wuzhouhui wrote: >> On Mar 2, 2019, at 8:21 AM, Daniel Shahaf wrote: >> >> wuzhouhui wrote on Fri, Mar 01, 2019 at 17:46:55 +0800: -Original Messages- From: "Branko Čibej" Sent Time: 2019-03-01 17:16:40 (Friday) To: users@subversion.apache.org Cc: Subject: Re: How to open specified inside .svn There are no such generic functions. The svn_wc API isn't really meant to be public, so you'll have to write your own access functions. Look at how the svn_client implementations do it, or for example svn_wc__get_pristine_contents_by_checksum in svn_wc_private.h. >>> Actually, I'm hacking Subversion client command line tool, so it >>> doesn't matter whether the API is public or private. >> The difference isn't just visibility. We don't promise compatibility >> for private APIs, not even across patch releases in the same minor line >> (1.A.x and 1.A.y). > Thanks for your reminding. I have implement client side pre-commit hook. > The implementation maybe ugly, but it works at least. > > In case of someone have interests, you can find my customized Subversion > in https://github.com/wuzhouhui/subversion. Please forgive me about using > Git to version control Subversion :-) Using git is not a problem. Calling it Subversion _is_ a problem. Please rename it to something else. -- Brane
X.509 Certificate Chain
1-USERTrust RSA Certification Authority.cer Description: application/x509-ca-cert 2-SSL.com High Assurance CA.cer Description: application/x509-ca-cert 3-*.apache.org.cer Description: application/x509-ca-cert
Re: Replacing directory by circular symlink produces malformed XML
Denis Excoffier wrote on Sat, 02 Mar 2019 09:17 +00:00: > What would be the best strategy? I can figure out this one: > > 1) Within the working copy, delete the existing tree (not svn delete) > 2) Extract the new tree at the same place > 3) Interpret the result of 'svn status' in terms of 'svn add' and > 'svn delete' to apply on the working copy (details omitted here) > 4) Commit > That should work, though the 'svn status' will be expensive because the usual optimization (not read()ing a file in full if its size+mtime haven't changed) won't kick in. In step 3 you can do 'svn add --force ./'. There's an addremove branch [1] that attempts to implement this, but I don't know what its state is. (It's named after the analogous hg command.) [1] https://svn.apache.org/viewvc/subversion/branches/addremove/ > The difficulty is to make sure that all peculiarities of a file system > changes (say: only files, folders and symlinks) are handled properly. > I don't talk about I/O errors of course. Yeah, I see no reason why it shouldn't be possible to version circular symlinks. You can certainly create them with svnmucc, for example. Cheers, Daniel
Re: How to open specified inside .svn
wuzhouhui wrote on Sat, 02 Mar 2019 04:29 +00:00: > In case of someone have interests, you can find my customized Subversion > in https://github.com/wuzhouhui/subversion. I think you want svn_io_check_resolved_path() there, no svn_io_check_path(). > Please forgive me about using Git to version control Subversion :-) FYI, there is https://github.com/apache/subversion/. Cheers, Daniel
Re: Replacing directory by circular symlink produces malformed XML
> On 2019-03-01 11:53, Stefan Sperling wrote: > >> > > Hi Denis, > > This problem is not specific to symbolic links. > There are quite a few cases where --xml produces invalid XML > when it runs into some kind of error. Perhaps the command > line client should be fixed to close open XML tags when an > error occurs, though this also risks people or scripts not > noticing such errors. > Thanks, but let's me explain it otherwise: I have access to the source tree of some development project that is *not* under any version control system. I would like to build a minimal level of versioning by committing this source tree into Subversion at regular intervals, e.g. each day (automatically). What would be the best strategy? I can figure out this one: 1) Within the working copy, delete the existing tree (not svn delete) 2) Extract the new tree at the same place 3) Interpret the result of 'svn status' in terms of 'svn add' and 'svn delete' to apply on the working copy (details omitted here) 4) Commit The difficulty is to make sure that all peculiarities of a file system changes (say: only files, folders and symlinks) are handled properly. I don't talk about I/O errors of course. Denis Excoffier.
