Re: svn log gives E130003: Malformed XML via DAV

[Franz Sirl]

Hi Nathan,

after further checking it turns out the failure mode I see is exactly 
the same like issue 4856, only you need to use --verbose and http to see 
it (`r` is the repository like created by `repro-4856.sh`):


```
> svn log --xml --verbose --use-merge-history -r 9:10 http://svn/r/A4 
>/dev/null

svn: E175009: The XML response contains invalid XML
svn: E130003: Malformed XML: mismatched tag at line 57
```

Looking into the intermediate XML on the wire shows the same missing 
log-item end tag. Again with file: access the XML looks fine.


Franz

Re: svn log gives E130003: Malformed XML via DAV

[Franz Sirl]

Am 2024-10-02 um 17:10 schrieb Franz Sirl:

So I came up with the attached tentative and so far untested patch.
I'm currently building packages and will test them as soon as build is 
finished.


Unfortunately the patch is just papering over the real bug. The XML 
error is gone, but the transferred XML is still truncated.
So it seems the bug is really about handling the sizes of the transfer 
buffers, though the compressed (1,063,630 bytes, ~ 1MiB + 16 KiB) and 
uncompressed (13,725,443 bytes) XML sizes don't look typical buffer sizes...


Anyway, fixing this likely requires far more insight into the subversion 
code than I have. So unless I get some hints on where to look, I'm out 
for now.

But if there is anything for me to help with, just let me know.

Franz

Re: svn log gives E130003: Malformed XML via DAV

[Franz Sirl]

Am 2024-10-02 um 16:02 schrieb Nathan Hartman:

On Tue, Oct 1, 2024 at 10:03 AM Franz Sirl
 wrote:

Looking at the transferred data with wireshark shows this at the end:
```

...
... (>4 lines of modified-path/added-path redacted)
...

```

So the closing tag `` is missing. This closing tag is only
sent by log_revision_receiver() in subversion/mod_dav_svn/reports/log.c
and is used as a callback in
subversion/libsvn_repos/log.c.
Looking at the code the only failure mode I could imagine so far is that
if the last revision processed for this transaction ends up with
`baton.found_rev_of_interest = FALSE`.
In this case send_log() doesn't call callbacks->revision_receiver() and
so the log-item tag never gets closed?



Thank you for the analysis.

Would you say that the Issue 4711 patch in the issue tracker [3]
improves the situation, even if it's still missing something?


To make it clear, all the tests I've done on client+server have
the patch [3] applied. It's in use for quite some time here without
bad effects (and fixed the problem for us, the reporter of 4711 is a 
colleague of mine). I believe the log-item bug is totally separate

bug on server-side. I just meant to express that maybe a similar
missing corner case handling (like 4711 on client) is the reason
for this bug on the server-side.


If we suspect that baton.found_rev_of_interest being FALSE for the
last processed revision causes the missing tag, we'll need to come up
with a reproduction recipe that triggers that. Could you rerun the
command but with a revision range where the last revision *is* of
interest, and tell us if the XML is formed correctly?


The command worked well for a long time, only after one of my colleagues 
committed a merge from the trunk to this release branch it stopped to work.
This merge contained mergeinfo about the merged trunk revisions and also 
mergeinfo about the merges from the colleagues user branch to trunk.
Probably this changed internal processing order in a way that made a 
baton.found_rev_of_interest=FALSE come as the last log-item.
With a http:// URL the command fails midway while outputting the XML 
resulting in a truncated file (2.8M size). With a file:// URL the XML is 
5.4M in size and passes (with --incremental removed) a validity check 
with `jing -c subversion/svn/schema/log.rnc`.


After thinking about it some more it occurred to me that since file:// 
is OK, subversion/libsvn_repos/log.c should be fine and rather the 
problem is in subversion/mod_dav_svn/reports/log.c.

So I came up with the attached tentative and so far untested patch.
I'm currently building packages and will test them as soon as build is 
finished.


BTW, it would make comparing/diffing the XML easier if both file:// and 
http:// outputs would use the same template to output the  tag.


Franz
Index: subversion-1.14.x/subversion/mod_dav_svn/reports/log.c
===
--- subversion-1.14.x/subversion/mod_dav_svn/reports/log.c  (revision 
1921084)
+++ subversion-1.14.x/subversion/mod_dav_svn/reports/log.c  (working copy)
@@ -61,6 +61,9 @@
  callbacks. */
   svn_boolean_t needs_log_item;
 
+  /* Whether we've written the  closure for the current report. */
+  svn_boolean_t needs_log_item_closure;
+
   /* How deep we are in the log message tree.  We only need to surpress the
  SVN_INVALID_REVNUM message if the stack_depth is 0. */
   int stack_depth;
@@ -107,11 +110,28 @@
   SVN_ERR(dav_svn__brigade_printf(lrb->bb, lrb->output,
   "" DEBUG_CR));
   lrb->needs_log_item = FALSE;
+  lrb->needs_log_item_closure = TRUE;
 }
 
   return SVN_NO_ERROR;
 }
 
+/* If LRB->needs_log_item_closure is true, send the ""
+   end element and set LRB->needs_log_item_closure to zero.
+   Else do nothing. */
+static svn_error_t *
+maybe_end_log_item(struct log_receiver_baton *lrb)
+{
+  if (lrb->needs_log_item_closure)
+{
+  SVN_ERR(dav_svn__brigade_printf(lrb->bb, lrb->output,
+  "" DEBUG_CR));
+  lrb->needs_log_item_closure = FALSE;
+}
+
+  return SVN_NO_ERROR;
+}
+
 /* Utility for log_receiver opening a new XML element in LRB's brigade
for LOG_ITEM and return the element's name in *ELEMENT.  Use POOL for
temporary allocations.
@@ -322,6 +342,7 @@
 
   SVN_ERR(dav_svn__brigade_puts(lrb->bb, lrb->output,
 "" DEBUG_CR));
+  lrb->needs_log_item_closure = FALSE;
 
   /* In general APR will flush the brigade every 8000 bytes through the filter
  stack, but log items may not be generated that fast, especially in
@@ -493,6 +514,7 @@
   lrb.output = output;
   lrb.needs_header = TRUE;
   lrb.needs_log_item = TRUE;
+  lrb.needs_log_item_closure = FALSE;
   lrb.stack_depth = 0;
   /* lrb.requested_custom_revprops set above */
 
@@ -536,6 +558,14 @@
   goto cleanup;
 }
 
+  if ((serr = maybe_end_log_item(&lrb)))
+{
+  derr = dav_s

Re: svn log gives E130003: Malformed XML via DAV

[Nathan Hartman]

On Wed, Oct 2, 2024 at 10:02 AM Nathan Hartman  wrote:
>
> On Tue, Oct 1, 2024 at 10:03 AM Franz Sirl
>  wrote:
> >
> > Hi,
> >
> > recently this svn log command started to fail like that:
> >
> > ```
> >  > svn log --xml --verbose --search @ --use-merge-history --incremental
> > --revision 172342:{2024-09-30}
> > http://svn/svn/project/branches/cd/2024_09 >/dev/null
> > svn: E175009: The XML response contains invalid XML
> > svn: E130003: Malformed XML: mismatched tag at line 139122
> > ```
> >
> > Removing the --verbose lets the command succeed, so it seems related to
> > the sending of the changed pathes. Also running the command with a
> > file:// URL directly on the server works fine.
> >
> > Server and client are 1.14.3+issue4711-fix (BTW, when will there be an
> > official release with the fix for issue 4711?) running on x64-linux.
> > Actually the failure mode looks quite similar to issue 4711, but this
> > time the problem happens on the server side.
>
>
> I thought I remembered fix(es) for unbalanced XML closing tags being
> implemented, committed, and backported to the 1.14.x branch!! But
> looking through the history, I only see two regression tests that were
> committed and both are @XFail() (meaning, expected FAILs).
>
> Those tests were committed to trunk in r1877310 and r1897133.
>
> Now, it seems there are two issues in the issue tracker related to
> this: Issue 4711 [1] (which you referenced) and Issue 4856 [2]. I'm
> adding a note to both...
>
>
> > Looking at the transferred data with wireshark shows this at the end:
> > ```
> > 
> >  > prop-mods="false">...
> > ... (>4 lines of modified-path/added-path redacted)
> >  > prop-mods="false">...
> > 
> > ```
> >
> > So the closing tag `` is missing. This closing tag is only
> > sent by log_revision_receiver() in subversion/mod_dav_svn/reports/log.c
> > and is used as a callback in
> > subversion/libsvn_repos/log.c.
> > Looking at the code the only failure mode I could imagine so far is that
> > if the last revision processed for this transaction ends up with
> > `baton.found_rev_of_interest = FALSE`.
> > In this case send_log() doesn't call callbacks->revision_receiver() and
> > so the log-item tag never gets closed?
>
>
> Thank you for the analysis.
>
> Would you say that the Issue 4711 patch in the issue tracker [3]
> improves the situation, even if it's still missing something?
>
> If we suspect that baton.found_rev_of_interest being FALSE for the
> last processed revision causes the missing tag, we'll need to come up
> with a reproduction recipe that triggers that. Could you rerun the
> command but with a revision range where the last revision *is* of
> interest, and tell us if the XML is formed correctly?
>
>
> > Hope this helps to track down the bug,
> > Franz
> >
> > PS: While investigating that I found a small cosmetic bug in the
> > prototype (fortunately the code follows the definition) for do_logs() in
> > subversion/libsvn_repos/log.c:
> > ```
> > Index: subversion/libsvn_repos/log.c
> > ===
> > --- subversion/libsvn_repos/log.c   (revision 1921065)
> > +++ subversion/libsvn_repos/log.c   (working copy)
> > @@ -1719,8 +1719,8 @@
> >   int limit,
> >   svn_boolean_t strict_node_history,
> >   svn_boolean_t include_merged_revisions,
> > +svn_boolean_t subtractive_merge,
> >   svn_boolean_t handling_merged_revisions,
> > -svn_boolean_t subtractive_merge,
> >   svn_boolean_t ignore_missing_locations,
> >   const apr_array_header_t *revprops,
> >   svn_boolean_t descending_order,
> > ```
>
>
> Good catch! The 11th and 12th arguments are swapped in the forward
> declaration. I'll commit this fix in a bit, but before I do that, I
> want to go over the call sites and verify they do not have the
> arguments swapped due to copying-and-pasting of the (wrong) forward
> declaration. Hopefully as you say the code follows the definition (and
> not the forward declaration).
>
> Thanks again,
> Nathan


Forgot to include the links... doh!

[1] Issue 4711: https://issues.apache.org/jira/browse/SVN-4711?issueNumber=4711

[2] Issue 4856: https://issues.apache.org/jira/browse/SVN-4856?issueNumber=4856

[3] Patch in issue tracker for Issue 4711:
https://issues.apache.org/jira/secure/attachment/13045647/4711_patch_new.txt

Re: svn log gives E130003: Malformed XML via DAV

[Nathan Hartman]

On Tue, Oct 1, 2024 at 10:03 AM Franz Sirl
 wrote:
>
> Hi,
>
> recently this svn log command started to fail like that:
>
> ```
>  > svn log --xml --verbose --search @ --use-merge-history --incremental
> --revision 172342:{2024-09-30}
> http://svn/svn/project/branches/cd/2024_09 >/dev/null
> svn: E175009: The XML response contains invalid XML
> svn: E130003: Malformed XML: mismatched tag at line 139122
> ```
>
> Removing the --verbose lets the command succeed, so it seems related to
> the sending of the changed pathes. Also running the command with a
> file:// URL directly on the server works fine.
>
> Server and client are 1.14.3+issue4711-fix (BTW, when will there be an
> official release with the fix for issue 4711?) running on x64-linux.
> Actually the failure mode looks quite similar to issue 4711, but this
> time the problem happens on the server side.


I thought I remembered fix(es) for unbalanced XML closing tags being
implemented, committed, and backported to the 1.14.x branch!! But
looking through the history, I only see two regression tests that were
committed and both are @XFail() (meaning, expected FAILs).

Those tests were committed to trunk in r1877310 and r1897133.

Now, it seems there are two issues in the issue tracker related to
this: Issue 4711 [1] (which you referenced) and Issue 4856 [2]. I'm
adding a note to both...


> Looking at the transferred data with wireshark shows this at the end:
> ```
> 
>  prop-mods="false">...
> ... (>4 lines of modified-path/added-path redacted)
>  prop-mods="false">...
> 
> ```
>
> So the closing tag `` is missing. This closing tag is only
> sent by log_revision_receiver() in subversion/mod_dav_svn/reports/log.c
> and is used as a callback in
> subversion/libsvn_repos/log.c.
> Looking at the code the only failure mode I could imagine so far is that
> if the last revision processed for this transaction ends up with
> `baton.found_rev_of_interest = FALSE`.
> In this case send_log() doesn't call callbacks->revision_receiver() and
> so the log-item tag never gets closed?


Thank you for the analysis.

Would you say that the Issue 4711 patch in the issue tracker [3]
improves the situation, even if it's still missing something?

If we suspect that baton.found_rev_of_interest being FALSE for the
last processed revision causes the missing tag, we'll need to come up
with a reproduction recipe that triggers that. Could you rerun the
command but with a revision range where the last revision *is* of
interest, and tell us if the XML is formed correctly?


> Hope this helps to track down the bug,
> Franz
>
> PS: While investigating that I found a small cosmetic bug in the
> prototype (fortunately the code follows the definition) for do_logs() in
> subversion/libsvn_repos/log.c:
> ```
> Index: subversion/libsvn_repos/log.c
> ===
> --- subversion/libsvn_repos/log.c   (revision 1921065)
> +++ subversion/libsvn_repos/log.c   (working copy)
> @@ -1719,8 +1719,8 @@
>   int limit,
>   svn_boolean_t strict_node_history,
>   svn_boolean_t include_merged_revisions,
> +svn_boolean_t subtractive_merge,
>   svn_boolean_t handling_merged_revisions,
> -svn_boolean_t subtractive_merge,
>   svn_boolean_t ignore_missing_locations,
>   const apr_array_header_t *revprops,
>   svn_boolean_t descending_order,
> ```


Good catch! The 11th and 12th arguments are swapped in the forward
declaration. I'll commit this fix in a bit, but before I do that, I
want to go over the call sites and verify they do not have the
arguments swapped due to copying-and-pasting of the (wrong) forward
declaration. Hopefully as you say the code follows the definition (and
not the forward declaration).

Thanks again,
Nathan

RE: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users]

> This may be a silly question, but has hardware been checked? I would
> start by checking: network wiring to the machine; the machine's RAM.

I don't mind silly; I'm just that desperate.  I'll do what I can to check those 
things, but given that I've seen the same results with the test server on a 
physical machine and a virtual machine, it's probably a long shot.  Both 
machines are pretty quiet, plenty of RAM, disk, and CPU.  And I wouldn't think 
a hardware issue would be resolved by moving to an https://localhost URL.

If I find something awry, I'll post.  Thanks for the suggestion.

Jim

Re: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Nathan Hartman]

On Thu, Sep 26, 2024 at 4:57 PM Williams, James P. {Jim} (JSC-CD4)[KBR
Wyle Services, LLC] via users  wrote:
>
> I was pulled away from this problem, so I quoted our last exchange.  Daniel, 
> you asked to test svn co but keeping communications entirely on the server 
> machine.  I did that by using an https://localhost URL.  I also had to turn 
> off Kerberos authentication, use "Require all granted", and hide the 
> AuthzSVNAccessFile.  I assume Kerberos was failing because the Server 
> Principal Name doesn't use localhost, and I assume AuthzSVNAccessFile doesn't 
> work with "Require all granted".
>
>
>
> With those changes, checkouts consistently succeed to either local disk or an 
> NFS mount.  I also don't see core dumps from the client (recall 90% of 
> attempts hang, 5% core dump, and 5% succeed).  That sounds like a useful data 
> point, but I'm not sure what to do with it.  It points at our network.  My 
> system administrators are convinced there's no proxy or reverse proxy.  I 
> expect there is security scanning going on, but it's nothing our production 
> server hasn't handled fine for many years.  It's also an Apache HTTP server, 
> but uses SVN 1.9.7.
>
>
>
> Thanks for any direction you can give me toward a solution.

Hi Jim,

This may be a silly question, but has hardware been checked? I would
start by checking: network wiring to the machine; the machine's RAM.

Thanks,
Nathan

RE: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users]

I was pulled away from this problem, so I quoted our last exchange.  Daniel, 
you asked to test svn co but keeping communications entirely on the server 
machine.  I did that by using an https://localhost URL.  I also had to turn off 
Kerberos authentication, use "Require all granted", and hide the 
AuthzSVNAccessFile.  I assume Kerberos was failing because the Server Principal 
Name doesn't use localhost, and I assume AuthzSVNAccessFile doesn't work with 
"Require all granted".

With those changes, checkouts consistently succeed to either local disk or an 
NFS mount.  I also don't see core dumps from the client (recall 90% of attempts 
hang, 5% core dump, and 5% succeed).  That sounds like a useful data point, but 
I'm not sure what to do with it.  It points at our network.  My system 
administrators are convinced there's no proxy or reverse proxy.  I expect there 
is security scanning going on, but it's nothing our production server hasn't 
handled fine for many years.  It's also an Apache HTTP server, but uses SVN 
1.9.7.

Thanks for any direction you can give me toward a solution.

Jim

From: Daniel Sahlberg 
Sent: Sunday, June 2, 2024 10:04 AM
Den mån 27 maj 2024 kl 14:18 skrev Johan Corveleyn 
mailto:jcor...@gmail.com>>:
On Sat, May 25, 2024 at 12:12 AM Williams, James P. {Jim}
(JSC-CD4)[KBR Wyle Services, LLC] via users
mailto:users@subversion.apache.org>> wrote:
>
> > Den lör 11 maj 2024 kl 03:00 skrev Williams, James P. {Jim} (JSC-CD4)[KBR 
> > Wyle Services, LLC] via users 
> > mailto:users@subversion.apache.org>>:
>
> > You previously mentioned Subversion 1.14.1, is that on the server or on the 
> > client?
>
> I'm using 1.14.1 on both the client and server.
>
> > Still it would be interesting to compare just to rule out a problem within 
> > the repository. You can use svnserve directly or tunneled over SSH, see the 
> > Subversion book:
>
> With svnserve 1.14.1, I see no problems.  Checkouts complete every time.  I'm 
> not sure what to conclude about that.  It's a different protocol, so it 
> doesn't necessarily exonerate the client or the network.
>
> > >   #0  epoll_wait   /usr/lib64/libc.so.6
>
> > Waiting for a reply from the server ... ?
>
> Yeah, that'd be my guess.  When the hang occurs, I've got about 90% of the 
> working copy checked out.  I expect the client is waiting for more bytes to 
> arrive on the socket.
>
> > Do you see any activity on the server (CPU / disk) during this time?
>
> The server is well-behaved throughout all of my tests.  It shows no CPU spike 
> or log messages hinting that it's noticed a problem.

That's why my bet is still on "something between client and server"
(proxy, reverse-proxy, security scanning soft, ...) that messes with
the network transfer (http or https). That would explain the symptoms
you're seeing (client hangs waiting for network (and sometimes
crashes), server has nothing to do and doesn't report anything
special).

I agree with Johan and I understand it might be hard to nail down the actual 
issue.

I don't think I have asked this before:
- Can you log in to the server and do an svn checkout 
https://localhost/[...] locally and does this succeed? 
You might have to update the Apache HTTPD configuration to allow the vhost to 
reply to "localhost" (or you could add the server name to the local hosts file 
pointing to 127.0.0.1 and do a checkout of 
https://[server]/[url]). What I'd like to accomplish 
is a checkout that doesn't leave the machine. Does this make a difference?

Kind regards,
Daniel

Re: How do I determine if a directory is part of a Subversion working copy?

[Vincent Lefevre]

On 2024-09-25 22:30:40 +0900, Yasuhito FUTATSUKI wrote:
> Then nothing is future-proof. We should check changes,
> forever.

So, shouldn't Subversion provide a command (e.g. svn subcommand) to
tell whether some directory is a working copy? The command should
either give the answer, with a zero exit status, or fail because it
cannot determine the answer (e.g. due to permission denied or because
the database is locked).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: How do I determine if a directory is part of a Subversion working copy?

[Yasuhito FUTATSUKI]

Hello,

On 2024/09/25 19:04, Vincent Lefevre wrote:
> Hi,
> 
> On 2024-09-25 11:58:43 +0900, Yasuhito FUTATSUKI wrote:
>> On 2024/09/25 9:17, Vincent Lefevre wrote:
>>
>>  > Checking the error message might not be future-proof.
>>
>> Then, check the error code instead.
> 
> It might not be future-proof either. For instance, there has been
> a change in 1.7, as noted there:
> 
> https://subversion.apache.org/docs/api/1.8/svn__error__codes_8h.html#ac8784565366c15a28d456c4997963660a46befa5b8c1fb5204fdc3921c3124b97
> 
> I suppose that if the error message changes, there is a high risk
> that the error code might change too, like above.

At least in Subversion 1.x, we would keep effort for backward
compatibility. Actually, SVN_ERR_WC_NOT_DIRECTORY can be still
used as an alias for backward compatibility and its acutal
error number is same as SVN_ERR_WC_NOT_WORKING_COPY.

However, the worry that an error code could be splitted
to more detailed errors, is reasonable.

Then nothing is future-proof. We should check changes,
forever.

>> e.g. with Python bindings:
> [...]
> 
> For portability, it needs to be a shell script (BTW, I've seen more
> breakage due to Python upgrades than anything else, so that Python
> is definitely not a good solution).

I used Python bindings as an example how to check symbolic error
code, but not a text literal. Because it might change on environment
it was built (at least it depends on APR_OS_START_USERERR comes
from an include file in APR library). I have no other intension.
Please use the way you like.

> With the shell command, there is the error code "E155007". So I'm
> wondering what is the most stable. I could not find any documentation
> on the subject.

One of obvious idea is check the error code for root path (assuming
it is not in working copy), before checking target paths, however
it root path itself is working copy, it might some other error than
SVN_ERR_WC_NOT_DIRECTORY, e.g. caused by wc.db locking.

Cheers,
-- 
Yasuhito FUTATSUKI 

Re: How do I determine if a directory is part of a Subversion working copy?

[Vincent Lefevre]

Hi,

On 2024-09-25 11:58:43 +0900, Yasuhito FUTATSUKI wrote:
> On 2024/09/25 9:17, Vincent Lefevre wrote:
> 
>  > Checking the error message might not be future-proof.
> 
> Then, check the error code instead.

It might not be future-proof either. For instance, there has been
a change in 1.7, as noted there:

https://subversion.apache.org/docs/api/1.8/svn__error__codes_8h.html#ac8784565366c15a28d456c4997963660a46befa5b8c1fb5204fdc3921c3124b97

I suppose that if the error message changes, there is a high risk
that the error code might change too, like above.

> e.g. with Python bindings:
[...]

For portability, it needs to be a shell script (BTW, I've seen more
breakage due to Python upgrades than anything else, so that Python
is definitely not a good solution).

With the shell command, there is the error code "E155007". So I'm
wondering what is the most stable. I could not find any documentation
on the subject.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: How do I determine if a directory is part of a Subversion working copy?

[Yasuhito FUTATSUKI]

Hello,

On 2024/09/25 9:17, Vincent Lefevre wrote:

 > Checking the error message might not be future-proof.

Then, check the error code instead.

e.g. with Python bindings:
[[[
import sys
from svn import core, client

def is_path_within_wc(path):
ret = True
try:
client.get_wc_root(core.svn_path_canonicalize(path),
   client.create_context())
except core.SubversionException as e:
if e.apr_err == core.SVN_ERR_WC_NOT_WORKING_COPY:
ret = False
else:
raise(e)
return ret

if __name__ == '__main__':
if len(sys.argv) != 2:
print('Usage: %s ' % sys.argv[0])
exit(2)
try:
print('yes' if is_path_within_wc(sys.argv[1]) else 'no')
except Exception as e:
print('error:', e)
exit(1)
]]]

Cheers,
-- 
Yasuhito FUTATSUKI 

Re: How to delete fiiles on the server that were accidentally part of an import?

[Daniel Sahlberg]

Den tis 24 sep. 2024 kl 09:30 skrev Bo Berglund :

> Here the URL delete command is described as follows:
>
> $ svn delete -m "Deleting file 'yourfile'" \
>  file:///var/svn/repos/test/yourfile
>
> And that did not make sense to me because file: is NOT in my view an URL
> and
> also because they had entered a \ in the middle of the command, which also
> does
> not make sense to me...
>

file:// is a URL with the protocol "file:", just as http:// is a URL with
the protocol "http:". It is meant to be adjusted to whatever the URL is for
your repository. Remember that SVN can use at least five different
protocols so any one chosen would be "wrong" for a majority of the readers,
but other examples use both http://, svn:// and svn+ssh://.

The backslash character is a continuation character used in many Unix
shells to break up the command to several separate lines. It is used to
indicate "don't expect that you can press enter after the log message and
enter the URL on the next line". As someone pointed out ^ can be used in
Windows for the same function.

I'd be happy if we can improve the book to be more clear in this regard -
feel free to make a suggestion.

Kind regards,
Daniel

Re: How to delete fiiles on the server that were accidentally part of an import?

[Bo Berglund]

On Tue, 24 Sep 2024 06:42:15 +, "Lorenz via users"
 wrote:

>Bo Berglund wrote:
>
>>I used the following command to import a folder with files into Subversion
>>without having to create a checked out copy of the new server side folder.
>>All of this on a single line in Windows cmd:
>>
>>
>>svn import LocalFolderName
>>https://oursvnservername/svn/pc/Name_of_project/tags/Name_of_project_6-3-3 -m
>>"Importing Name_of_project 6.3.3 for use when building the installers"
>>
>>After it completed I discovered that a few files that were *not* part of the
>>project to import were accidentally present in the local source folder...
>>
>>So now I wonder how I can delete these files *on the server* without first
>>checking out the project and svn remove them?
>>
>>Is there a corresponding server side delete that does not require a local copy
>>first?
>>
>>In the SvnBook I found this example, which I do not really understand:
>>
>>Deleting a URL, however, is immediate, so you have to supply a log message:
>>
>>$ svn delete -m "Deleting file 'yourfile'" \
>> file:///var/svn/repos/test/yourfile
>>
>>Committed revision 15.
>>
>>
>>I don't understand how the syntax should be especially the use of the 
>>backslash.
>>Why is that there?
>>
>>And my server target is *not* a file: rather it is an https URL as shown above
>>in my import command.
>>
>>Please explain.
>
>- regarding repo access URLs:
>https://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.wc.tbl-1
>
>- are you aware that svn delete removes its target from HEAD revision?
>The file/folder will still be in the repo and accessable going back in
>history.

I know that but I wanted to remove these files because they are not really part
of the fileset I need to be there. So in order to get a clean checkout/export I
needed to delete them.
Does not matter if they still remain in the repo in an earlier revision because
HEAD is what will always be used. They are support files for a build process.

I looked in my bookmarked version of the svnbook:
https://svnbook.red-bean.com/en/1.8/svn.ref.svn.c.delete.html

Here the URL delete command is described as follows:

$ svn delete -m "Deleting file 'yourfile'" \
 file:///var/svn/repos/test/yourfile

And that did not make sense to me because file: is NOT in my view an URL and
also because they had entered a \ in the middle of the command, which also does
not make sense to me...

But I tested with this instead (as I wrote in my next post):

svn delete -m "Deleting file xxx"
https://svnserver/svn/repo/tags/nameofproject/filetodelete

And this dis the job.


-- 
Bo Berglund
Developer in Sweden

Re: How to delete fiiles on the server that were accidentally part of an import?

[Lorenz via users]

Bo Berglund wrote:

>I used the following command to import a folder with files into Subversion
>without having to create a checked out copy of the new server side folder.
>All of this on a single line in Windows cmd:
>
>
>svn import LocalFolderName
>https://oursvnservername/svn/pc/Name_of_project/tags/Name_of_project_6-3-3 -m
>"Importing Name_of_project 6.3.3 for use when building the installers"
>
>After it completed I discovered that a few files that were *not* part of the
>project to import were accidentally present in the local source folder...
>
>So now I wonder how I can delete these files *on the server* without first
>checking out the project and svn remove them?
>
>Is there a corresponding server side delete that does not require a local copy
>first?
>
>In the SvnBook I found this example, which I do not really understand:
>
>Deleting a URL, however, is immediate, so you have to supply a log message:
>
>$ svn delete -m "Deleting file 'yourfile'" \
> file:///var/svn/repos/test/yourfile
>
>Committed revision 15.
>
>
>I don't understand how the syntax should be especially the use of the 
>backslash.
>Why is that there?
>
>And my server target is *not* a file: rather it is an https URL as shown above
>in my import command.
>
>Please explain.

- regarding repo access URLs:
https://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.wc.tbl-1

- are you aware that svn delete removes its target from HEAD revision?
The file/folder will still be in the repo and accessable going back in
history.
-- 

Lorenz

Re: How to delete fiiles on the server that were accidentally part of an import?

[Stanimir Stamenkov via users]

Mon, 23 Sep 2024 19:26:04 +0200, /Bo Berglund/:


By using this it did work (all on one line anmd no extra backslash):

svn delete -m "Deleting file xxx" 
https://svnserver/svn/repo/tags/nameofproject/filetodelete


In the Windows Command Prompt (cmd) or batch scripts you could use ^ 
(caret) [1]:


svn delete -m "Deleting file xxx" ^
https://svnserver/svn/repo/tags/nameofproject/filetodelete

Because ^ is the escape character in Windows cmd it needs to be escaped 
on its own when used literally 
:


Windows users should not forget that a caret is an escape character on 
their platform. Therefore, use a double caret ^^ ...


[1] https://ss64.com/nt/syntax-esc.html#crlf

--
Stanimir

Re: How to delete fiiles on the server that were accidentally part of an import?

[Bo Berglund]

On Mon, 23 Sep 2024 18:40:46 +0200, Bo Berglund  wrote:

>I used the following command to import a folder with files into Subversion
>without having to create a checked out copy of the new server side folder.
>All of this on a single line in Windows cmd:
>
>
>svn import LocalFolderName
>https://oursvnservername/svn/pc/Name_of_project/tags/Name_of_project_6-3-3 -m
>"Importing Name_of_project 6.3.3 for use when building the installers"
>
>After it completed I discovered that a few files that were *not* part of the
>project to import were accidentally present in the local source folder...
>
>So now I wonder how I can delete these files *on the server* without first
>checking out the project and svn remove them?
>
>Is there a corresponding server side delete that does not require a local copy
>first?
>
>In the SvnBook I found this example, which I do not really understand:
>
>Deleting a URL, however, is immediate, so you have to supply a log message:
>
>$ svn delete -m "Deleting file 'yourfile'" \
> file:///var/svn/repos/test/yourfile
>
>Committed revision 15.
>
>
>I don't understand how the syntax should be especially the use of the 
>backslash.
>Why is that there?
>
>And my server target is *not* a file: rather it is an https URL as shown above
>in my import command.
>
>Please explain.

Replying to self:

By using this it did work (all on one line anmd no extra backslash):

svn delete -m "Deleting file xxx"
https://svnserver/svn/repo/tags/nameofproject/filetodelete



-- 
Bo Berglund
Developer in Sweden

Re: Incomplete checkout into empty directory, presence of nodes are 'server-excluded'

[Jörg Dalkolmo]

Hello Johan,

Ok, thank you very much for the information.

Best,
Jörg

> Am 13.09.2024 um 16:38 schrieb Johan Corveleyn :
> 
> On Fri, Sep 13, 2024 at 3:27 PM Jörg Dalkolmo  wrote:
>> 
>> Hello Johan,
>> 
>> Thanx a lot for your annotations.
>> Unfortunately I am not allowed, and for us there is no colleague available 
>> to check the configuration on the SVN server if there are any path-based 
>> authorization settings, and if yes, if they affect our part of the 
>> repository.
>> 
>> Are there any other scenarios thinkable than failed authorization, which 
>> could lead to the ‚server-excluded‘ entry in the presence column? Perhaps 
>> interrupted connection from client to server, or something else?
> 
> Well, in theory there could be other reasons (all the client knows for
> sure is that the server excluded this node). But in practice, as far
> as I know, failed path-based authorization is the only reason for
> server-exclusion that has been implemented in the standard SVN server.
> 
> Specifically, an interrupted connection cannot cause 'server-excluded'
> nodes. Those would get a 'not-present' (for files) or 'incomplete'
> (for directories) status in the wc.db, as far as I remember.
> 
> --
> Johan

Re: Incomplete checkout into empty directory, presence of nodes are 'server-excluded'

[Johan Corveleyn]

On Fri, Sep 13, 2024 at 3:27 PM Jörg Dalkolmo  wrote:
>
> Hello Johan,
>
> Thanx a lot for your annotations.
> Unfortunately I am not allowed, and for us there is no colleague available to 
> check the configuration on the SVN server if there are any path-based 
> authorization settings, and if yes, if they affect our part of the repository.
>
> Are there any other scenarios thinkable than failed authorization, which 
> could lead to the ‚server-excluded‘ entry in the presence column? Perhaps 
> interrupted connection from client to server, or something else?

Well, in theory there could be other reasons (all the client knows for
sure is that the server excluded this node). But in practice, as far
as I know, failed path-based authorization is the only reason for
server-exclusion that has been implemented in the standard SVN server.

Specifically, an interrupted connection cannot cause 'server-excluded'
nodes. Those would get a 'not-present' (for files) or 'incomplete'
(for directories) status in the wc.db, as far as I remember.

-- 
Johan

Re: Incomplete checkout into empty directory, presence of nodes are 'server-excluded'

[Jörg Dalkolmo]

Hello Johan,

Thanx a lot for your annotations. 
Unfortunately I am not allowed, and for us there is no colleague available to 
check the configuration on the SVN server if there are any path-based 
authorization settings, and if yes, if they affect our part of the repository.

Are there any other scenarios thinkable than failed authorization, which could 
lead to the ‚server-excluded‘ entry in the presence column? Perhaps interrupted 
connection from client to server, or something else?

Best
Jörg

 
> Am 13.09.2024 um 13:02 schrieb Johan Corveleyn :
> 
> On Fri, Sep 13, 2024 at 9:40 AM Jörg Dalkolmo  wrote:
>> Hello Nathan!
>> 
>> Thank you very much for the quick and very valuable answer. I had searched 
>> the internet for ‚server-excluded‘ before and often ended up somewhere in 
>> the subversion source code, where ‚authz‘ is mentioned, so your hint 
>> encourages me, that some kind of selective permissions for the omitted dirs 
>> and files in the repository are the key for understanding the effect.
>> 
>> Subversion in our environment is hosted on a Linux system with apache web 
>> server; the clients are all TortoiseSVN on Windows servers, target 
>> directories for the working copies are administrative shares on those 
>> servers.
>> In one of our experiments we had the - for us - strange effect that for one 
>> target directory on one server all files and dirs were checked out, for 
>> another target directory on another server always the same files and dirs 
>> were omitted. That is:
>> 
>> //winserver1/adminshare1$/targetdir1/   gets all dirs and files.
>> //winserver2/adminshare2$/targetdir2/ does NOT get all dirs and files.
>> 
>> I have to mention that I am NOT the user that performs all the tortoiseSVN 
>> actions in our trials and I have no relevant experience with SVN, I am just 
>> part of the team that ponders about this problem that drives us crazy.
>> 
>> To cut a long story short, thank you very much again, I will encourage our 
>> team members to pursue this path.
> 
> Hi Jörg,
> 
> Nathan is referring to the built-in "path-based authorization" feature
> of SVN (where one can configure certain paths to be only accessed by
> certain (groups of) users). This is not managed inside the Apache
> httpd config, but in the path-based authorization file of SVN. This
> can be either a normal file on the server or a file in the repository
> itself (referenced by the AuthzSVNAccessFile or
> AuthzSVNReposRelativeAccessFile directives in the httpd config).
> 
> See these sections in the "SVN book" for more info:
> https://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html
> https://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authz.perdir
> 
> So probably, some of the files or dirs under
> //winserver2/adminshare2$/targetdir2/ are not-authorized for your user
> (as specified in the path-based authz file on the server).
> 
> -- 
> Johan

Re: Incomplete checkout into empty directory, presence of nodes are 'server-excluded'

[Johan Corveleyn]

On Fri, Sep 13, 2024 at 9:40 AM Jörg Dalkolmo  wrote:
> Hello Nathan!
>
> Thank you very much for the quick and very valuable answer. I had searched 
> the internet for ‚server-excluded‘ before and often ended up somewhere in the 
> subversion source code, where ‚authz‘ is mentioned, so your hint encourages 
> me, that some kind of selective permissions for the omitted dirs and files in 
> the repository are the key for understanding the effect.
>
> Subversion in our environment is hosted on a Linux system with apache web 
> server; the clients are all TortoiseSVN on Windows servers, target 
> directories for the working copies are administrative shares on those servers.
> In one of our experiments we had the - for us - strange effect that for one 
> target directory on one server all files and dirs were checked out, for 
> another target directory on another server always the same files and dirs 
> were omitted. That is:
>
> //winserver1/adminshare1$/targetdir1/   gets all dirs and files.
> //winserver2/adminshare2$/targetdir2/ does NOT get all dirs and files.
>
> I have to mention that I am NOT the user that performs all the tortoiseSVN 
> actions in our trials and I have no relevant experience with SVN, I am just 
> part of the team that ponders about this problem that drives us crazy.
>
> To cut a long story short, thank you very much again, I will encourage our 
> team members to pursue this path.

Hi Jörg,

Nathan is referring to the built-in "path-based authorization" feature
of SVN (where one can configure certain paths to be only accessed by
certain (groups of) users). This is not managed inside the Apache
httpd config, but in the path-based authorization file of SVN. This
can be either a normal file on the server or a file in the repository
itself (referenced by the AuthzSVNAccessFile or
AuthzSVNReposRelativeAccessFile directives in the httpd config).

See these sections in the "SVN book" for more info:
https://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html
https://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authz.perdir

So probably, some of the files or dirs under
//winserver2/adminshare2$/targetdir2/ are not-authorized for your user
(as specified in the path-based authz file on the server).

-- 
Johan

Re: Incomplete checkout into empty directory, presence of nodes are 'server-excluded'

[Jörg Dalkolmo]

Hello Nathan!

Thank you very much for the quick and very valuable answer. I had searched the 
internet for ‚server-excluded‘ before and often ended up somewhere in the 
subversion source code, where ‚authz‘ is mentioned, so your hint encourages me, 
that some kind of selective permissions for the omitted dirs and files in the 
repository are the key for understanding the effect. 
Subversion in our environment is hosted on a Linux system with apache web 
server; the clients are all TortoiseSVN on Windows servers, target directories 
for the working copies are administrative shares on those servers.
In one of our experiments we had the - for us - strange effect that for one 
target directory on one server all files and dirs were checked out, for another 
target directory on another server always the same files and dirs were omitted. 
That is:

//winserver1/adminshare1$/targetdir1/   gets all dirs and files.
//winserver2/adminshare2$/targetdir2/ does NOT get all dirs and files.

I have to mention that I am NOT the user that performs all the tortoiseSVN 
actions in our trials and I have no relevant experience with SVN, I am just 
part of the team that ponders about this problem that drives us crazy.

To cut a long story short, thank you very much again, I will encourage our team 
members to pursue this path.

Best
Jörg

> Am 13.09.2024 um 03:29 schrieb Nathan Hartman :
> 
> 
>> On Thu, Sep 12, 2024 at 12:57 PM Jörg Dalkolmo  wrote:
> 
>> Hello!
>> 
>> Our colleagues use TortoiseSVN to checkout a subdirectory of a repository 
>> into an empty target directory.
>> 
>> Sometimes this works perfect, but in the last time very often the checkout 
>> finishes without error messages, telling it has completed, but not all files 
>> were transferred to the target directory. Looking into the SQLite database 
>> "wc.db" of the working copy, in the nodes-table we find the missing files as 
>> entries with "server-excluded" in the column "presence". 
>> 
>> How can we track down the reason for the file being "server-excluded"?
>> 
>> Best
>> 
>> Jörg
>> 
> 
> 
> Hello Jörg,
> 
> I am aware of one condition that gives a presence of "server-excluded" and 
> that is when the repository has authz rules and the user is not authorized to 
> access that file or directory, so the server excludes it from the checkout. 
> 
> Hope this helps,
> Nathan
> 

Re: Incomplete checkout into empty directory, presence of nodes are 'server-excluded'

[Nathan Hartman]

On Thu, Sep 12, 2024 at 12:57 PM Jörg Dalkolmo  wrote:

> Hello!
>
> Our colleagues use TortoiseSVN to checkout a subdirectory of a repository
> into an empty target directory.
>
> Sometimes this works perfect, but in the last time very often the checkout
> finishes *without error message*s, telling it has completed, but not all
> files were transferred to the target directory. Looking into the SQLite
> database "wc.db" of the working copy, in the nodes-table we find the
> missing files as entries with "server-excluded" in the column "presence".
>
> How can we track down the reason for the file being "server-excluded"?
>
> Best
>
> Jörg
>

Hello Jörg,

I am aware of one condition that gives a presence of "server-excluded" and
that is when the repository has authz rules and the user is not authorized
to access that file or directory, so the server excludes it from the
checkout.

Hope this helps,
Nathan

Re: Issue with SVN Checkout Due to Malformed XML Response

[Daniel Sahlberg]

Den tis 10 sep. 2024 kl 22:20 skrev 耗子 :

> Dear Subversion Development Team,
> I hope this message finds you well.
> I am encountering a critical issue when attempting to check out a specific
> revision from the WordPress SVN repository. The command I used is:
>
> svn checkout -r 2983085
> https://plugins.svn.wordpress.org/acymailing-integration-for-memberpress
>

Your server seems to be running version 1.9.5. That is out of support since
many years. Can you update and check if the problem reproduces under
Subversion 1.14?

However, this results in the following error:
>
> svn: E175009: The XML response contains invalid XML
> svn: E130003: Malformed XML: not well-formed (invalid token) at line 55
>
> Upon investigation, I suspect that the issue lies in the tags section,
> specifically with the 2.2 tag, which might contain special characters that
> are causing this problem. The full URL for reference is:
>
>
> https://plugins.svn.wordpress.org/!svn/bc/2983085/acymailing-integration-for-memberpress/tags/
>
> I have reviewed the SVN issue tracker and searched for similar issues
> online, but I have not found any reports of this particular problem.
> Additionally, this issue also prevents me from using svnsync to mirror the
> entire repository, resulting in similar XML-related errors.
> Would it be possible for the development team to investigate this issue,
> or could you provide any guidance on how to resolve this malformed XML
> error?
> Thank you for your attention to this matter. I look forward to your
> feedback.
>

Agreed. It seems that the tag is named %1B%5BC2.2 (url-encoded). I assume
0x1B 0x5B is some unicode character. I can't determine if it is correct
that the tag should be named this way. But before spending more time, can
you please investigate if you can reproduce the issue with the latest
version?

Kind regards,
Daniel

Re: Deletion of Branches(Folder and Files) from SVN server

[Blake McBride]

Same answer!



On Sun, Sep 8, 2024 at 4:46 AM Nico Kadel-Garcia  wrote:

> On Fri, Sep 6, 2024 at 7:59 PM Blake McBride  wrote:
> >
> > On Tue, Jul 9, 2024 at 6:42 AM Nico Kadel-Garcia 
> wrote:
> >>
> >>
> >> There is a time where the "immutable history" becomes too expensive.
> >> Spending skull sweat trying to work past the inability to delete
> >> obsolete branches or commits also becomes overwhelming. At some point,
> >> at least with Subversion, you have to archive the old repo, keep it
> >> only for reference, and start over with a clean entirely new repo
> >> populated only by a copy of the contents, not of the history.
> >
> >
> > That's the answer!
>
> This is the case for the Subversino repo of subversion itself. It's
> gotten impossibly large and cannot be completely mirrored with
> ordinary tools anymore.
>

Re: Deletion of Branches(Folder and Files) from SVN server

[Nico Kadel-Garcia]

On Fri, Sep 6, 2024 at 7:59 PM Blake McBride  wrote:
>
> On Tue, Jul 9, 2024 at 6:42 AM Nico Kadel-Garcia  wrote:
>>
>>
>> There is a time where the "immutable history" becomes too expensive.
>> Spending skull sweat trying to work past the inability to delete
>> obsolete branches or commits also becomes overwhelming. At some point,
>> at least with Subversion, you have to archive the old repo, keep it
>> only for reference, and start over with a clean entirely new repo
>> populated only by a copy of the contents, not of the history.
>
>
> That's the answer!

This is the case for the Subversino repo of subversion itself. It's
gotten impossibly large and cannot be completely mirrored with
ordinary tools anymore.

Re: Deletion of Branches(Folder and Files) from SVN server

[Blake McBride]

On Tue, Jul 9, 2024 at 6:42 AM Nico Kadel-Garcia  wrote:

>
> There is a time where the "immutable history" becomes too expensive.
> Spending skull sweat trying to work past the inability to delete
> obsolete branches or commits also becomes overwhelming. At some point,
> at least with Subversion, you have to archive the old repo, keep it
> only for reference, and start over with a clean entirely new repo
> populated only by a copy of the contents, not of the history.
>

That's the answer!

RE: [EXTERNAL] Re: svnsync Error About Disallowed "non-regular" Property

[Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users]

Den fre 16 aug. 2024 kl 18:37 skrev Williams, James P. {Jim} (JSC-CD4)[KBR Wyle 
Services, LLC] via users 
mailto:users@subversion.apache.org>>:
I sort of did that before posting, but results depend on how and where I ask.

   # remote host, http:// finds nothing
   remote-host> svn propget --revprop -r 0 svn:entry:committed-date 
https://my/repo
   svn: E200017: Property 'svn:entry:committed-date' not found on revision 0

   # local host, http:// finds the property
   local-host> svn propget --revprop -r 0 svn:entry:committed-date 
https://my/repo
   1992-01-29T13:14:31.00Z

That is really weird. Are you sure the host "my" actually resolves to the same 
machine on both computers? Are you sure there are no proxies that affect the 
replies (in particular from remote-host)?

There's nothing between these two hosts.  But if there was, wouldn't that be 
even weirder?  Somehow, a proxy decided to hide this particular property, 
coincidentally the one I happen to be having issues with, but let all the 
others go through, unnoticed by the command line client.  It's very repeatable, 
and the command lines are identical for the https://my/repo case.

But I was able to remove the property from a range of revisions and multiple 
repos, so I'm thankful for the help.

Jim

Re: [EXTERNAL] Re: svnsync Error About Disallowed "non-regular" Property

[Daniel Sahlberg]

Den fre 16 aug. 2024 kl 18:37 skrev Williams, James P. {Jim} (JSC-CD4)[KBR
Wyle Services, LLC] via users :

> I sort of did that before posting, but results depend on how and where I
> ask.
>
># remote host, http:// finds nothing
>remote-host> svn propget --revprop -r 0 svn:entry:committed-date
> https://my/repo
>svn: E200017: Property 'svn:entry:committed-date' not found on revision
> 0
>
># local host, http:// finds the property
>local-host> svn propget --revprop -r 0 svn:entry:committed-date
> https://my/repo
>1992-01-29T13:14:31.00Z
>

That is really weird. Are you sure the host "my" actually resolves to the
same machine on both computers? Are you sure there are no proxies that
affect the replies (in particular from remote-host)?

Kind regards,
Daniel

RE: [EXTERNAL] Re: svnsync Error About Disallowed "non-regular" Property

[Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users]

> From: Andreas Stieger 
> Sent: Friday, August 16, 2024 4:08 AM
> > When I run the following on a number of my SVN repos,
> >
> >% svnsync initialize file:///my/mirror file:///my/original
> >
> > I get this error.
> >
> >svnsync: E165002: Storage of non-regular property
> > 'svn:entry:committed-date' is disallowed
> >
> >through the repository interface, and could indicate a bug in your
> > client
> >
> > I don't know where that property is to remove it or where it came
> > from. I assume it's something SVN puts there for its own bookkeeping.
> >
> > How do I get past this?
> >
> > This is with SVN 1.14.1.  Repo formats are all 5.  Just before running
> > svnsync, I used "svnadmin create" to create a fresh, empty mirror
> > repo, and added a pre-revprop-change hook that just exits.
> >
> 
> Check if your r0 of the source repository has this revision property set
> 
> svnlook proplist --revprop -r 0 REPOS_PATH
> 
> svnlook propget --revprop -r 0 REPO_PATH svn:entry:committed-date
> 
> If it does, you can remove it, see "svnadmin help delrevprop" etc.. That
> should enable the sync to be initialized.

I sort of did that before posting, but results depend on how and where I ask.

   # remote host, http:// finds nothing
   remote-host> svn propget --revprop -r 0 svn:entry:committed-date 
https://my/repo
   svn: E200017: Property 'svn:entry:committed-date' not found on revision 0

   # local host, http:// finds the property
   local-host> svn propget --revprop -r 0 svn:entry:committed-date 
https://my/repo
   1992-01-29T13:14:31.00Z

   # local host, file:// finds the property
   local-host> svn propget --revprop -r 0 svn:entry:committed-date 
file:///my/repo
   1992-01-29T13:14:31.00Z

That's just weird.  Before posting I had run only the first of those.  Any idea 
why the property is visible from one host but not another?

Regardless, you've helped me find a range of revisions that have the property, 
which I can easily remove.

Thanks.

Jim

Re: svnsync Error About Disallowed "non-regular" Property

[Andreas Stieger]

On 2024-08-16 00:58, Williams, James P. {Jim} (JSC-CD4)[KBR Wyle
Services, LLC] via users wrote:


When I run the following on a number of my SVN repos,

   % svnsync initialize file:///my/mirror file:///my/original

I get this error.

   svnsync: E165002: Storage of non-regular property
'svn:entry:committed-date' is disallowed

   through the repository interface, and could indicate a bug in your
client

I don't know where that property is to remove it or where it came
from. I assume it's something SVN puts there for its own bookkeeping.

How do I get past this?

This is with SVN 1.14.1.  Repo formats are all 5.  Just before running
svnsync, I used "svnadmin create" to create a fresh, empty mirror
repo, and added a pre-revprop-change hook that just exits.



Check if your r0 of the source repository has this revision property set

svnlook proplist --revprop -r 0 REPOS_PATH

svnlook propget --revprop -r 0 REPO_PATH svn:entry:committed-date

If it does, you can remove it, see "svnadmin help delrevprop" etc.. That
should enable the sync to be initialized.

Andreas

Re: Compatibility of Subversion 1.10

[Nico Kadel-Garcia]

On Tue, Aug 6, 2024 at 5:44 AM Daniel Sahlberg
 wrote:
>
> Den tis 6 aug. 2024 kl 11:29 skrev Aditi A :
>>
>> Hello Team,
>>
>> I hope this email finds you well.
>>
>> We are planning to upgrade our RHEL server from version 7 to 8. According to 
>> the RHEL 8 release notes, it uses Subversion 1.10. I wanted to confirm the 
>> compatibility of Subversion 1.10 with Apache, Perl, and curl.
>>
>> Could you please let me know the suitable versions of Apache, Perl, and curl 
>> that work well with Subversion 1.10?
>
> Subversion 1.10 is out of support since over two years so we can't give you 
> an updated answer, nor support you if you run into trouble.
>
> Red Hat will probably make sure that the versions of Apache Httpd, Perl etc 
> included in RHEL are compatible with the version of Subversion in the same 
> distribution. It is probably best to direct any questions through your 
> support contract with Red Hat.
>
> Kind regards,
> Daniel Sahlberg

Good guess, I've worked with them all within RHEL 8. Since RHEL 10 is
in pre-release as "CentOS 10 Stream", I'd update to RHEL 9 to ensure
longevity and security updates of the underlying httpd.

Re: Compatibility of Subversion 1.10

[Daniel Sahlberg]

Den tis 6 aug. 2024 kl 11:29 skrev Aditi A :

> Hello Team,
>
> I hope this email finds you well.
>
> We are planning to upgrade our RHEL server from version 7 to 8. According
> to the RHEL 8 release notes, it uses Subversion 1.10. I wanted to confirm
> the compatibility of Subversion 1.10 with Apache, Perl, and curl.
>
> Could you please let me know the suitable versions of Apache, Perl, and
> curl that work well with Subversion 1.10?
>
Subversion 1.10 is out of support since over two years so we can't give you
an updated answer, nor support you if you run into trouble.

Red Hat will probably make sure that the versions of Apache Httpd, Perl etc
included in RHEL are compatible with the version of Subversion in the same
distribution. It is probably best to direct any questions through your
support contract with Red Hat.

Kind regards,
Daniel Sahlberg


Thank you for your assistance.
>
> Aditi
>

Re: [Bugs] svnlook history --limit

[Daniel Sahlberg]

ons 24 juli 2024 kl. 11:36 skrev zongganli(李宗淦) :

> Hello,
>
> We found a bug in svnlook history --limit.
> It can not deal with the illegal input like "-1", as "apr_size_t" could
> be unsigned.
>
> We have fixed the bug, should we send the patch to
> d...@subversion.apache.org or start a issuse first.
>

Please send it to d...@subversion.apache.org. The issue tracker is only used
for long-standing issues.

Kind regards
Daniel

Re: Deletion of Branches(Folder and Files) from SVN server

[Nico Kadel-Garcia]

On Tue, Jul 9, 2024 at 6:13 AM Bo Berglund  wrote:
>
> On Tue, 2 Jul 2024 20:39:12 +0530, Roshan Pardeshi 
> wrote:
>
> >We require to delete the branches(folder and files) from SVN server to
> >release some space from disk as we are facing space crunch on disk in SVN
> >server.
>
> Following this discussion it seems like the best approach would be to buy
> yourself a larger disk and then transfer the content of the small disk to
> that...
>
> SVN has as its basic idea:
> "keep everything forever so older data can be extracted"
>
> Disk space is cheap these days and you are wasting many hours of costly work
> time trying to circumvent the purchase of a disk

Replication time, and backup space, aren't free, especially for high
reliability services or the performance you may want for a bulky
source control project.

There is a time where the "immutable history" becomes too expensive.
Spending skull sweat trying to work past the inability to delete
obsolete branches or commits also becomes overwhelming. At some point,
at least with Subversion, you have to archive the old repo, keep it
only for reference, and start over with a clean entirely new repo
populated only by a copy of the contents, not of the history.

Re: Deletion of Branches(Folder and Files) from SVN server

[Bo Berglund]

On Tue, 2 Jul 2024 20:39:12 +0530, Roshan Pardeshi 
wrote:

>We require to delete the branches(folder and files) from SVN server to
>release some space from disk as we are facing space crunch on disk in SVN
>server.

Following this discussion it seems like the best approach would be to buy
yourself a larger disk and then transfer the content of the small disk to
that...

SVN has as its basic idea:
"keep everything forever so older data can be extracted"

Disk space is cheap these days and you are wasting many hours of costly work
time trying to circumvent the purchase of a disk


-- 
Bo Berglund
Developer in Sweden

Re: Deletion of Branches(Folder and Files) from SVN server

[Andreas Stieger]

Hello,

On 2024-07-02 17:09, Roshan Pardeshi wrote:

We require to delete the branches(folder and files) from SVN server to
release some space from disk as we are facing space crunch on disk in
SVN server.

Please help on this as what command we should use to delete the
branches(folder and files). We have used below command but its not working

1. svn delete branch name
2. svnadmin delete branch name
3. svn rm branch name
4. svnadmin rm branch name
5. del branch name



In addition to the guidance given about the svn repository being
immutable, and towards possible filtering, let me share the following:

Check for old, uncommitted transactions taking up disk space. If they
are old you can remove them as they are unlikely to ever become a
revision. On disk this is db/transactions which you can check for space.
To operated on them I recommend you use "svnadmin lstxns" / "svnadmin
rmtxns".

$ svnadmin help lstxns
lstxns: usage: svnadmin lstxns REPOS_PATH

Print the names of uncommitted transactions. With -rN skip the output
of those that have a base revision more recent than rN. Transactions
with base revisions much older than HEAD are likely to have been
abandoned and are candidates to be removed.

Valid options:
  -r [--revision] ARG  : transaction base revision ARG

$ svnadmin help rmtxns
rmtxns: usage: svnadmin rmtxns REPOS_PATH TXN_NAME...

Delete the named transaction(s).


Andreas

Re: Deletion of Branches(Folder and Files) from SVN server

[Nico Kadel-Garcia]

On Fri, Jul 5, 2024 at 9:29 AM Nathan Hartman 
wrote:

> On Fri, Jul 5, 2024 at 6:59 AM Daniel Sahlberg <
> daniel.l.sahlb...@gmail.com> wrote:
>
>> Den fre 5 juli 2024 kl 12:44 skrev Roshan Pardeshi <
>> roshan.parde...@ncdex.com>:
>>
>>> Hello Nathan/ Team,
>>>
>>> Waitng for your revert on trail nail.
>>>
>>
>> The short answer is that you can't decrease the disk usage from the
>> repository. The repository is immutable and you can't change history.
>>
>> A branch is in general quite lightweight and only stores the information
>> that has changed in that particular branch so I'm not sure exactly how much
>> data you will save by deleting old branches.
>>
>> If you REALLY need to remove things, you could use `svnrdump` or
>> `svnadmin dump` with the --include/--exclude options to only dump the
>> revisions/paths you want to keep. Then you load the dumpfle to a new
>> repository using `svnadmin load` (you should use the --ignore-uuid option
>> when loading). When you do this, all existing working copies will be
>> invalid and the users need to check out new working copies.
>>
>> Please check the help texts for more information.
>>
>> Kind regards,
>> Daniel
>>
>
The "svnadmin dump" approach requires shell access on the primary server.
If you *can*, setting up svnsync to a second server to get a working and
maintainable, up-to-date copy to attempt dumps and pruning operations from.
It can get *expensive* to set up such spaces with an oversized repository,
and be quite impossible to complete the initial svnsync operation, as it is
impossible to complete for the primary subversion repo for subversion
itself.

Re: Deletion of Branches(Folder and Files) from SVN server

[Nathan Hartman]

On Fri, Jul 5, 2024 at 6:59 AM Daniel Sahlberg 
wrote:

> Den fre 5 juli 2024 kl 12:44 skrev Roshan Pardeshi <
> roshan.parde...@ncdex.com>:
>
>> Hello Nathan/ Team,
>>
>> Waitng for your revert on trail nail.
>>
>
> The short answer is that you can't decrease the disk usage from the
> repository. The repository is immutable and you can't change history.
>
> A branch is in general quite lightweight and only stores the information
> that has changed in that particular branch so I'm not sure exactly how much
> data you will save by deleting old branches.
>
> If you REALLY need to remove things, you could use `svnrdump` or `svnadmin
> dump` with the --include/--exclude options to only dump the revisions/paths
> you want to keep. Then you load the dumpfle to a new repository using
> `svnadmin load` (you should use the --ignore-uuid option when loading).
> When you do this, all existing working copies will be invalid and the users
> need to check out new working copies.
>
> Please check the help texts for more information.
>
> Kind regards,
> Daniel
>
>
>
>>
>> Regards,
>>
>>
>>  
>> 
>> 
>>
>> Roshan Pardeshi
>> Senior Executive
>> National Commodity & Derivatives Exchange Limited
>>
>> <#m_4205676612975724340_m_262593516953184_m_3282584026429926061_m_5264752297521101632_SignatureSanitizer_SafeHtmlFilter_>
>> 9167426129
>> <#m_4205676612975724340_m_262593516953184_m_3282584026429926061_m_5264752297521101632_SignatureSanitizer_SafeHtmlFilter_>
>>  /  022 - 6640 3225
>> <#m_4205676612975724340_m_262593516953184_m_3282584026429926061_m_5264752297521101632_SignatureSanitizer_SafeHtmlFilter_>
>> roshan.parde...@ncdex.com
>> 
>> /as...@ncdex.com
>> 
>> Toll-free number 1800 266 2339 / 1800 103 4861
>> <#m_4205676612975724340_m_262593516953184_m_3282584026429926061_m_5264752297521101632_SignatureSanitizer_SafeHtmlFilter_>
>>
>>
>>
>> On Wed, Jul 3, 2024 at 7:46 PM Roshan Pardeshi 
>> wrote:
>>
>>> Hello Nathan,
>>>
>>> Please find the inputs below inline.
>>>
>>> What version of Subversion is used on the server?  *svn, version
>>> 1.7.14 (r1542130)*
>>>
>>> How big is the repository? ---  *1.5 TB*
>>>
>>> How many revisions in the repository? --- *Please confirm how to
>>> and where to find revisions in the repository*
>>>
>>> What format is the repository backend? (bdb or fsfs?)  *Please
>>> confirm where to check the format of repository backend*
>>>
>>> Regards*,*
>>>
>>>
>>>  
>>> 
>>> 
>>>
>>> Roshan Pardeshi
>>> Senior Executive
>>> National Commodity & Derivatives Exchange Limited
>>>
>>> <#m_4205676612975724340_m_262593516953184_m_3282584026429926061_m_5264752297521101632_m_-7064375209309644506_SignatureSanitizer_SafeHtmlFilter_>
>>> 9167426129
>>> <#m_4205676612975724340_m_262593516953184_m_3282584026429926061_m_5264752297521101632_m_-7064375209309644506_SignatureSanitizer_SafeHtmlFilter_>
>>>  /  022 - 6640 3225
>>> <#m_4205676612975724340_m_262593516953184_m_3282584026429926061_m_5264752297521101632_m_-7064375209309644506_SignatureSanitizer_SafeHtmlFilter_>
>>> roshan.parde...@ncdex.com
>>> 
>>> /as...@ncdex.com
>>> 
>>> Toll-free number 1800 266 2339 / 1800 103 4861
>>> <#m_4205676612975724340_m_262593516953184_m_3282584026429926061_m_5264752297521101632_m_-7064375209309644506_SignatureSanitizer_SafeHtmlFilter_>
>>>
>>>
>>>
>>> On Tue, Jul 2, 2024 at 9:58 PM Nathan Hartman 
>>> wrote:
>>>
 On Tue, Jul 2, 2024 at 11:23 AM Roshan Pardeshi <
 roshan.parde...@ncdex.com> wrote:

> Hello,
>
> We require to delete the branches(folder and files) from SVN server to
> release some space from disk as we are facing space crunch on disk in SVN
> server.
>
> Please help on this as what command we should use to delete the
> branches(folder and files). We have used below command but its not working
>
> 1. svn delete branch name
> 2. svnadmin delete branch name
> 3. svn rm branch name
> 4.  svnadmin  rm branch name
> 5. del branch name
>
> Regards,
>


 Hi,

 Please note that deleting a branch in Subversion does not remove the
 information from your server, nor free any disk space. Since Subversion
 always keeps historical information, the data will still be there, even if
 it appears to be gone moving forward from the latest revision. It is always
 possible to update to an older revision to make the delet

Re: Deletion of Branches(Folder and Files) from SVN server

[Daniel Sahlberg]

Den fre 5 juli 2024 kl 12:44 skrev Roshan Pardeshi <
roshan.parde...@ncdex.com>:

> Hello Nathan/ Team,
>
> Waitng for your revert on trail nail.
>

The short answer is that you can't decrease the disk usage from the
repository. The repository is immutable and you can't change history.

A branch is in general quite lightweight and only stores the information
that has changed in that particular branch so I'm not sure exactly how much
data you will save by deleting old branches.

If you REALLY need to remove things, you could use `svnrdump` or `svnadmin
dump` with the --include/--exclude options to only dump the revisions/paths
you want to keep. Then you load the dumpfle to a new repository using
`svnadmin load` (you should use the --ignore-uuid option when loading).
When you do this, all existing working copies will be invalid and the users
need to check out new working copies.

Please check the help texts for more information.

Kind regards,
Daniel



>
> Regards,
>
>
>  
> 
> 
>
> Roshan Pardeshi
> Senior Executive
> National Commodity & Derivatives Exchange Limited
> <#m_5264752297521101632_SignatureSanitizer_SafeHtmlFilter_>
> 9167426129 <#m_5264752297521101632_SignatureSanitizer_SafeHtmlFilter_> /  022
> - 6640 3225 <#m_5264752297521101632_SignatureSanitizer_SafeHtmlFilter_>
> roshan.parde...@ncdex.com
> /
> as...@ncdex.com
> 
> Toll-free number 1800 266 2339 / 1800 103 4861
> <#m_5264752297521101632_SignatureSanitizer_SafeHtmlFilter_>
>
>
>
> On Wed, Jul 3, 2024 at 7:46 PM Roshan Pardeshi 
> wrote:
>
>> Hello Nathan,
>>
>> Please find the inputs below inline.
>>
>> What version of Subversion is used on the server?  *svn, version
>> 1.7.14 (r1542130)*
>>
>> How big is the repository? ---  *1.5 TB*
>>
>> How many revisions in the repository? --- *Please confirm how to and
>> where to find revisions in the repository*
>>
>> What format is the repository backend? (bdb or fsfs?)  *Please
>> confirm where to check the format of repository backend*
>>
>> Regards*,*
>>
>>
>>  
>> 
>> 
>>
>> Roshan Pardeshi
>> Senior Executive
>> National Commodity & Derivatives Exchange Limited
>>
>> <#m_5264752297521101632_m_-7064375209309644506_SignatureSanitizer_SafeHtmlFilter_>
>> 9167426129
>> <#m_5264752297521101632_m_-7064375209309644506_SignatureSanitizer_SafeHtmlFilter_>
>>  /  022 - 6640 3225
>> <#m_5264752297521101632_m_-7064375209309644506_SignatureSanitizer_SafeHtmlFilter_>
>> roshan.parde...@ncdex.com
>> 
>> /as...@ncdex.com
>> 
>> Toll-free number 1800 266 2339 / 1800 103 4861
>> <#m_5264752297521101632_m_-7064375209309644506_SignatureSanitizer_SafeHtmlFilter_>
>>
>>
>>
>> On Tue, Jul 2, 2024 at 9:58 PM Nathan Hartman 
>> wrote:
>>
>>> On Tue, Jul 2, 2024 at 11:23 AM Roshan Pardeshi <
>>> roshan.parde...@ncdex.com> wrote:
>>>
 Hello,

 We require to delete the branches(folder and files) from SVN server to
 release some space from disk as we are facing space crunch on disk in SVN
 server.

 Please help on this as what command we should use to delete the
 branches(folder and files). We have used below command but its not working

 1. svn delete branch name
 2. svnadmin delete branch name
 3. svn rm branch name
 4.  svnadmin  rm branch name
 5. del branch name

 Regards,

>>>
>>>
>>> Hi,
>>>
>>> Please note that deleting a branch in Subversion does not remove the
>>> information from your server, nor free any disk space. Since Subversion
>>> always keeps historical information, the data will still be there, even if
>>> it appears to be gone moving forward from the latest revision. It is always
>>> possible to update to an older revision to make the deleted data reappear.
>>> This is the purpose of version control.
>>>
>>> If you can tell us a little more about the Subversion server and the
>>> repository, we can suggest possible steps you can take. Specifically:
>>>
>>> What version of Subversion is used on the server?
>>>
>>> How big is the repository?
>>>
>>> How many revisions in the repository?
>>>
>>> What format is the repository backend? (bdb or fsfs?)
>>>
>>> Thanks,
>>> Nathan
>>>
>>>
>>>
> Experience *'tick-by-tick*' broadcast on NCDEX's NextGen trading
> platform. *www.ncdex.com *
>
> *Tweet: @ncdex, Facebook: TrustNCDEX, Youtube: NCDEX Ltd.*
>
> *Disclaimer:*
>
> *This email and any and all attachment/s hereto are intended solely for
> the ad

Re: Deletion of Branches(Folder and Files) from SVN server

[Roshan Pardeshi]

Hello Nathan/ Team,

Waitng for your revert on trail nail.

Regards,


 



Roshan Pardeshi
Senior Executive
National Commodity & Derivatives Exchange Limited
<#SignatureSanitizer_SafeHtmlFilter_>
9167426129 <#SignatureSanitizer_SafeHtmlFilter_> /  022 - 6640 3225
<#SignatureSanitizer_SafeHtmlFilter_>
roshan.parde...@ncdex.com
/
as...@ncdex.com

Toll-free number 1800 266 2339 / 1800 103 4861
<#SignatureSanitizer_SafeHtmlFilter_>



On Wed, Jul 3, 2024 at 7:46 PM Roshan Pardeshi 
wrote:

> Hello Nathan,
>
> Please find the inputs below inline.
>
> What version of Subversion is used on the server?  *svn, version
> 1.7.14 (r1542130)*
>
> How big is the repository? ---  *1.5 TB*
>
> How many revisions in the repository? --- *Please confirm how to and
> where to find revisions in the repository*
>
> What format is the repository backend? (bdb or fsfs?)  *Please
> confirm where to check the format of repository backend*
>
> Regards*,*
>
>
>  
> 
> 
>
> Roshan Pardeshi
> Senior Executive
> National Commodity & Derivatives Exchange Limited
> <#m_-7064375209309644506_SignatureSanitizer_SafeHtmlFilter_>
> 9167426129 <#m_-7064375209309644506_SignatureSanitizer_SafeHtmlFilter_> /  022
> - 6640 3225 <#m_-7064375209309644506_SignatureSanitizer_SafeHtmlFilter_>
> roshan.parde...@ncdex.com
> /
> as...@ncdex.com
> 
> Toll-free number 1800 266 2339 / 1800 103 4861
> <#m_-7064375209309644506_SignatureSanitizer_SafeHtmlFilter_>
>
>
>
> On Tue, Jul 2, 2024 at 9:58 PM Nathan Hartman 
> wrote:
>
>> On Tue, Jul 2, 2024 at 11:23 AM Roshan Pardeshi <
>> roshan.parde...@ncdex.com> wrote:
>>
>>> Hello,
>>>
>>> We require to delete the branches(folder and files) from SVN server to
>>> release some space from disk as we are facing space crunch on disk in SVN
>>> server.
>>>
>>> Please help on this as what command we should use to delete the
>>> branches(folder and files). We have used below command but its not working
>>>
>>> 1. svn delete branch name
>>> 2. svnadmin delete branch name
>>> 3. svn rm branch name
>>> 4.  svnadmin  rm branch name
>>> 5. del branch name
>>>
>>> Regards,
>>>
>>
>>
>> Hi,
>>
>> Please note that deleting a branch in Subversion does not remove the
>> information from your server, nor free any disk space. Since Subversion
>> always keeps historical information, the data will still be there, even if
>> it appears to be gone moving forward from the latest revision. It is always
>> possible to update to an older revision to make the deleted data reappear.
>> This is the purpose of version control.
>>
>> If you can tell us a little more about the Subversion server and the
>> repository, we can suggest possible steps you can take. Specifically:
>>
>> What version of Subversion is used on the server?
>>
>> How big is the repository?
>>
>> How many revisions in the repository?
>>
>> What format is the repository backend? (bdb or fsfs?)
>>
>> Thanks,
>> Nathan
>>
>>
>>

-- 


Experience *'tick-by-tick*' broadcast on NCDEX's NextGen trading 
platform. **www.ncdex.com **

*Tweet: @ncdex, 
Facebook: TrustNCDEX, Youtube: NCDEX Ltd.*
**

*Disclaimer:*

*This email 
and any and all attachment/s hereto are intended solely for the 
addressee/s, are strictly confidential and may be privileged. If you are 
not the intended recipient, any reading, dissemination, copying or any 
other use of this e-mail and the attachment/s is prohibited. If you have 
received this email in error, please notify the sender immediately by email 
and also permanently delete the email. Copyright reserved.*

*All 
communications, incoming and outgoing, may be recorded and are monitored 
for legitimate business purposes. NCDEX is not responsible for any damage 
caused by virus or alteration of the e-mail or the accompanying 
attachment/s by a third party or otherwise. NCDEX disclaims all liability 
for any loss or damage whatsoever arising out of or resulting from the 
receipt, use, transmission or interruption of this email. Any views or 
opinions expressed in this email are those of the author only.*

Re: Deletion of Branches(Folder and Files) from SVN server

[Lorenz via users]

Hi,

Roshan Pardeshi wrote:
>Hello Nathan,
>
>Please find the inputs below inline.
>
>What version of Subversion is used on the server?  *svn, version 1.7.14
>(r1542130)*
>
>How big is the repository? ---  *1.5 TB*
>
>How many revisions in the repository? --- *Please confirm how to and
>where to find revisions in the repository*
>
>What format is the repository backend? (bdb or fsfs?)  *Please confirm
>where to check the format of repository backend*

svnadmin info path-to-repo
-- 

Lorenz


>
>Regards*,*
>
>
> 
>
>
>
>Roshan Pardeshi
>Senior Executive
>National Commodity & Derivatives Exchange Limited
><#SignatureSanitizer_SafeHtmlFilter_>
>9167426129 <#SignatureSanitizer_SafeHtmlFilter_> /  022 - 6640 3225
><#SignatureSanitizer_SafeHtmlFilter_>
>roshan.parde...@ncdex.com
>/
>as...@ncdex.com
>
>Toll-free number 1800 266 2339 / 1800 103 4861
><#SignatureSanitizer_SafeHtmlFilter_>
>
>
>
>On Tue, Jul 2, 2024 at 9:58?PM Nathan Hartman 
>wrote:
>
>> On Tue, Jul 2, 2024 at 11:23 AM Roshan Pardeshi 
>> wrote:
>>
>>> Hello,
>>>
>>> We require to delete the branches(folder and files) from SVN server to
>>> release some space from disk as we are facing space crunch on disk in SVN
>>> server.
>>>
>>> Please help on this as what command we should use to delete the
>>> branches(folder and files). We have used below command but its not working
>>>
>>> 1. svn delete branch name
>>> 2. svnadmin delete branch name
>>> 3. svn rm branch name
>>> 4.  svnadmin  rm branch name
>>> 5. del branch name
>>>
>>> Regards,
>>>
>>
>>
>> Hi,
>>
>> Please note that deleting a branch in Subversion does not remove the
>> information from your server, nor free any disk space. Since Subversion
>> always keeps historical information, the data will still be there, even if
>> it appears to be gone moving forward from the latest revision. It is always
>> possible to update to an older revision to make the deleted data reappear.
>> This is the purpose of version control.
>>
>> If you can tell us a little more about the Subversion server and the
>> repository, we can suggest possible steps you can take. Specifically:
>>
>> What version of Subversion is used on the server?
>>
>> How big is the repository?
>>
>> How many revisions in the repository?
>>
>> What format is the repository backend? (bdb or fsfs?)
>>
>> Thanks,
>> Nathan
>>
>>
>>

Re: Deletion of Branches(Folder and Files) from SVN server

[Roshan Pardeshi]

Hello Nathan,

Please find the inputs below inline.

What version of Subversion is used on the server?  *svn, version 1.7.14
(r1542130)*

How big is the repository? ---  *1.5 TB*

How many revisions in the repository? --- *Please confirm how to and
where to find revisions in the repository*

What format is the repository backend? (bdb or fsfs?)  *Please confirm
where to check the format of repository backend*

Regards*,*


 



Roshan Pardeshi
Senior Executive
National Commodity & Derivatives Exchange Limited
<#SignatureSanitizer_SafeHtmlFilter_>
9167426129 <#SignatureSanitizer_SafeHtmlFilter_> /  022 - 6640 3225
<#SignatureSanitizer_SafeHtmlFilter_>
roshan.parde...@ncdex.com
/
as...@ncdex.com

Toll-free number 1800 266 2339 / 1800 103 4861
<#SignatureSanitizer_SafeHtmlFilter_>



On Tue, Jul 2, 2024 at 9:58 PM Nathan Hartman 
wrote:

> On Tue, Jul 2, 2024 at 11:23 AM Roshan Pardeshi 
> wrote:
>
>> Hello,
>>
>> We require to delete the branches(folder and files) from SVN server to
>> release some space from disk as we are facing space crunch on disk in SVN
>> server.
>>
>> Please help on this as what command we should use to delete the
>> branches(folder and files). We have used below command but its not working
>>
>> 1. svn delete branch name
>> 2. svnadmin delete branch name
>> 3. svn rm branch name
>> 4.  svnadmin  rm branch name
>> 5. del branch name
>>
>> Regards,
>>
>
>
> Hi,
>
> Please note that deleting a branch in Subversion does not remove the
> information from your server, nor free any disk space. Since Subversion
> always keeps historical information, the data will still be there, even if
> it appears to be gone moving forward from the latest revision. It is always
> possible to update to an older revision to make the deleted data reappear.
> This is the purpose of version control.
>
> If you can tell us a little more about the Subversion server and the
> repository, we can suggest possible steps you can take. Specifically:
>
> What version of Subversion is used on the server?
>
> How big is the repository?
>
> How many revisions in the repository?
>
> What format is the repository backend? (bdb or fsfs?)
>
> Thanks,
> Nathan
>
>
>

-- 


Experience *'tick-by-tick*' broadcast on NCDEX's NextGen trading 
platform. **www.ncdex.com **

*Tweet: @ncdex, 
Facebook: TrustNCDEX, Youtube: NCDEX Ltd.*
**

*Disclaimer:*

*This email 
and any and all attachment/s hereto are intended solely for the 
addressee/s, are strictly confidential and may be privileged. If you are 
not the intended recipient, any reading, dissemination, copying or any 
other use of this e-mail and the attachment/s is prohibited. If you have 
received this email in error, please notify the sender immediately by email 
and also permanently delete the email. Copyright reserved.*

*All 
communications, incoming and outgoing, may be recorded and are monitored 
for legitimate business purposes. NCDEX is not responsible for any damage 
caused by virus or alteration of the e-mail or the accompanying 
attachment/s by a third party or otherwise. NCDEX disclaims all liability 
for any loss or damage whatsoever arising out of or resulting from the 
receipt, use, transmission or interruption of this email. Any views or 
opinions expressed in this email are those of the author only.*

Re: Deletion of Branches(Folder and Files) from SVN server

[Nathan Hartman]

On Tue, Jul 2, 2024 at 11:23 AM Roshan Pardeshi 
wrote:

> Hello,
>
> We require to delete the branches(folder and files) from SVN server to
> release some space from disk as we are facing space crunch on disk in SVN
> server.
>
> Please help on this as what command we should use to delete the
> branches(folder and files). We have used below command but its not working
>
> 1. svn delete branch name
> 2. svnadmin delete branch name
> 3. svn rm branch name
> 4.  svnadmin  rm branch name
> 5. del branch name
>
> Regards,
>


Hi,

Please note that deleting a branch in Subversion does not remove the
information from your server, nor free any disk space. Since Subversion
always keeps historical information, the data will still be there, even if
it appears to be gone moving forward from the latest revision. It is always
possible to update to an older revision to make the deleted data reappear.
This is the purpose of version control.

If you can tell us a little more about the Subversion server and the
repository, we can suggest possible steps you can take. Specifically:

What version of Subversion is used on the server?

How big is the repository?

How many revisions in the repository?

What format is the repository backend? (bdb or fsfs?)

Thanks,
Nathan

Re: Nginx reverse proxy corrupting filenames

[Gustavo Chaves]

Em qui., 20 de jun. de 2024 às 16:15, Daniel Sahlberg
 escreveu:
>
> Have you seen the FAQ item about reverse proxies:

Yes, I have.

> I have absolutely no experience with Nginx but this seems to set the 
> Destination header, much like the examples in the FAQ for IIS. But it seems 
> it keep the hostname and port - maybe you need to change it a bit more to 
> match what Apache Httpd is expecting (hostname localhost, port 3691).

It makes sense!

I tried to reconfigure it so that it'd change the hostname and the
port in the Destination header. So far it hasn't worked, but I'll keep
trying a little more.

> If you get this to work, would you consider writing an instruction that we 
> could add to the FAQ? Nginx has been mentioned in the past but I don't know 
> if anyone got it to work.

Will do!

Thank you very much, Daniel.

-- 
Gustavo

Re: PoshSvn – Subversion for PowerShell

[Timofey Zhakov]

On Thu, Jun 20, 2024 at 8:58 PM Daniel Sahlberg
 wrote:
>
> Den tors 20 juni 2024 kl 20:27 skrev Timofey Zhakov :
>>
>>
>> The actual name of the project is 'PoshSvn'; not 'Poshsvn'. Could you
>> please fix it?
>
>
> Oops, I know I missed something. Sorry and thanks for the review. Fixed in 
> r1918475 - ok now?

Yes, it's OK. Thank you!

-- 
Timofei Zhakov

Re: Nginx reverse proxy corrupting filenames

[Daniel Sahlberg]

Hi Gustavo!

Have you seen the FAQ item about reverse proxies:

https://subversion.apache.org/faq.html#reverseproxy

It doesn't have any specific information about Nginx but maybe you can get
a hint at the correct information based on the reverse proxy instructions
for Apache Httpd and IIS.

Den tors 20 juni 2024 kl 19:18 skrev Gustavo Chaves :

> I have a Subversion vesion 1.14.1 running behind a reverse proxy
> implemented by nginx version 1.18.0 on a Ubuntu 22.04 server.
>
> I'm having problems renaming files in it. I came up with the following
> procedure to reproduce the problem:
>
> > $ export LANG=C.UTF-8
> > $ export LANGUAGE=en
> > $ REPO=https://svn.domain.mine/repo
> >
> > $ svn co $REPO/trunk repo
> > Checked out revision 19.
> >
> > $ cd repo
> >
> > $ echo doit >'plano de acao.txt'
> >
> > $ svn add 'plano de acao.txt'
> > A plano de acao.txt
> >
> > $ svn commit -m'add file'
> > Adding plano de acao.txt
> > Transmitting file data .done
> > Committing transaction...
> > Committed revision 20.
> >
> > $ ls -lA
> > total 8
> > drwxrwxr-x 4 gustavo gustavo 4096 Jun 20 13:39  .svn
> > -rw-rw-r-- 1 gustavo gustavo5 Jun 20 13:40 'plano de acao.txt'
> >
> > $ svn mv 'plano de acao.txt' 'action plan.txt'
> > A action plan.txt
> > D plano de acao.txt
> >
> > $ svn commit -m'rename file'
> > Adding action plan.txt
> > Deleting   plano de acao.txt
> > Committing transaction...
> > Committed revision 21.
> >
> > $ ls -lA
> > total 8
> > drwxrwxr-x 4 gustavo gustavo 4096 Jun 20 13:39  .svn
> > -rw-rw-r-- 1 gustavo gustavo5 Jun 20 13:40 'action plan.txt'
> >
> > $ svn up
> > Updating '.':
> > svn: E175009: The XML response contains invalid XML
> > svn: E130003: Malformed XML: no element found at line 10
> >
> > $ cd ..
> >
> > $ rm -rf repo
> >
> > $ svn co $REPO/trunk repo
> > Arepo/action%20plan.txt
> > Checked out revision 21.
> >
> > $ cd repo
> >
> > $ ls -lA
> > total 8
> > drwxrwxr-x 4 gustavo gustavo 4096 Jun 20 13:42 .svn
> > -rw-rw-r-- 1 gustavo gustavo5 Jun 20 13:42 action%20plan.txt
> >
> > $ svn up
> > Updating '.':
> > At revision 21.
>
> Note the error message in the first "svn up" and also that the space
> in the filename is checked out as "%20".
>
> I can reproduce this problem only when I access the repository via an
> URL that goes through the nginx reverse proxy. If I try via an URL
> that goes directly to Apache httpd or locally (file://) the problem
> does not happen.
>
> This is the Nginx's server configuration I'm using for the proxy:
>
> > server {
> >   listen  443 ssl;
> >   server_name svn.domain.mine;
> >
> >   client_body_timeout 3600s;
> >   client_max_body_size 10m;
> >   keepalive_timeout 3600s;
> >   send_timeout 3600s;
> >
> >   location / {
> > proxy_pass   http://localhost:3691;
> > proxy_set_header X-Forwarded-For $remote_addr;
> > proxy_set_header Host$host;
> > proxy_buffering off;
> > proxy_request_buffering off;
> >
> > # See
> https://sigterm.sh/2012/10/09/nginx-apache-2-and-subversion-502-bad-gateway-error/
> > set $fixed_destination $http_destination;
> > if ( $http_destination ~* ^https(.*)$ )
> > {
> >   set $fixed_destination http$1;
> > }
> > proxy_set_header Destination $fixed_destination;
>

I have absolutely no experience with Nginx but this seems to set the
Destination header, much like the examples in the FAQ for IIS. But it seems
it keep the hostname and port - maybe you need to change it a bit more to
match what Apache Httpd is expecting (hostname localhost, port 3691).

>   }
> > }
>
> I wasn't able to find any mention of a similar problem via Google or
> in Subversion's Jira.
>
> Can you help me figure this out, please?
>

If you get this to work, would you consider writing an instruction that we
could add to the FAQ? Nginx has been mentioned in the past but I don't know
if anyone got it to work.

Kind regards,
Daniel Sahlberg

Re: PoshSvn – Subversion for PowerShell

[Daniel Sahlberg]

Den tors 20 juni 2024 kl 20:27 skrev Timofey Zhakov :

>
> The actual name of the project is 'PoshSvn'; not 'Poshsvn'. Could you
> please fix it?
>

Oops, I know I missed something. Sorry and thanks for the review. Fixed in
r1918475 - ok now?

Kind regards,
Daniel

Re: PoshSvn – Subversion for PowerShell

[Timofey Zhakov]

On Thu, Jun 20, 2024 at 8:06 PM Daniel Sahlberg
 wrote:
>
> Den sön 19 maj 2024 kl 13:47 skrev Timofey Zhakov :
>>
>> Dear Daniel,
>>
>> On Fri, May 17, 2024 at 9:54 AM Daniel Sahlberg 
>>  wrote:
>>>
>>> Den fre 17 maj 2024 kl 06:45 skrev Nathan Hartman 
>>> :

 On Thu, May 16, 2024 at 1:50 PM Timofey Zhakov  wrote:
 >
 > Hello everyone!
 >
 > I like Subversion and use it for my projects.
 >
 > PoshSvn is a PowerShell module which provides a tab competition and
 > typed output for the Subversion cmdlets. I found it useful for
 > scripting and everyday life
>>
>>   [...]
>>>
>>> Dear Timofei,
>>>
>>> Very impressive work and I think this is the biggest addition to the 
>>> Subversion ecosystem in may years.
>>
>> Thanks!
>>
>>>
>>>
>>> I'm a Windows user although I use PowerShell way to seldom. I will try to 
>>> find time to test this out a little bit in the next few weeks.
>>>
>>> I was thinking about adding a link to your project on the Subversion 
>>> website. There is already page for Binary packages[1] and this would make a 
>>> nice addition. (Although, we have previously limited that page to strictly 
>>> Apache Subversion builds and this a different kind of client, so we might 
>>> have to create a new page for "ecosystem" - this should be discussed in the 
>>> dev@ list).
>>
>> Yes, it would be nice to add a link to my project to the Subversion website. 
>> The PoshSvn MSI installer also provides Subversion binaries, so it might be 
>> on the page for Binary packages.
>
>
> I finally got down to this e-mail and added the link to the staging website 
> in r1918474.
>
> See https://subversion-staging.apache.org/packages.html#windows
>
> I'll merge to publish shortly.

Thank you so much!

The actual name of the project is 'PoshSvn'; not 'Poshsvn'. Could you
please fix it?

--
Timofei Zhakov

Re: Migration from CentOS 7, Subversion 1.94 to Ubuntu 24.04, SVN 1.14.3

[Paul Leo]

List responders -

Once again thanks everyone for taking the time to respond and all of 
your suggestions.


On 6/19/2024 2:58 AM, Daniel Sahlberg wrote:
Den tis 18 juni 2024 kl 23:19 skrev Paul Leo 
:

...

The reason I am posting here instead of TortoiseSVN is I would
like to know whether it would be safer to have folks just do a new
checkout from new server once old server is shutdown, (and diff
folders if needed) instead of trying relocate, or should I have
them edit the wc.db and replace or try and change the uuid on the
new server to match the old one.


Since you use TortoiseSVN, the other option would be to remove the 
.svn folder and do a new checkout in the same directory. TortoiseSVN 
is quite nice that it picks up the existing files and says "Versioned" 
on them and you can usually continue as before. The command line 
client seems to mark the existing files as "Conflict" and require a 
lot of manual work to resolve. Of course, test it first but it might 
be an easier solution than manually carrying over any changes to the 
new working copy.


I'd avoid editing wc.db - it usually works but I'd be careful asking 
endusers to do it.


Kind regards,
Daniel

Re: Migration from CentOS 7, Subversion 1.94 to Ubuntu 24.04, SVN 1.14.3

[Nico Kadel-Garcia]

On Wed, Jun 19, 2024 at 3:31 AM Andreas Stieger  wrote:
>
>
> On 2024-06-18 23:19, Paul Leo wrote:
> > If I try a relocate in TortoiseSVN, I get an error saying the uuid of
> > the new server is different than the WC of the local repo.   I presume
> > this is because of the DNS name change.
>
>
> No, this is because the UUID is different.

It's similar to the TLS certificate for HTTPS access, or the SSH
hostkey for SSH access. It helps ensure that you connect to the
correct, expected source of "truth" for your source control system.

> > I've done some searching and have followed a suggestion and edited the
> > wc.db and replaced old server uuid with new server uuid, tried the
> > relocate command again and things seem to be working and pointing to
> > new server.
> >
>
> No, see "svnadmin help setuuid"

Seconded. You can seriously hurt yourself manually editing such files.

> > I also know that doing a new checkout from the new server may be the
> > simplest solution. But perhaps some folks will not commit all of their
> > changes before switchover because they are not ready.
> >
>
> Make the old one read-only via a pre-commit hook if you can.
>
>
> Andreas

Give that man a cookie. "Split brain" is a real risk if you
accidentally kept both repositories live and accepting commits.

Re: Migration from CentOS 7, Subversion 1.94 to Ubuntu 24.04, SVN 1.14.3

[Daniel Sahlberg]

Den tis 18 juni 2024 kl 23:19 skrev Paul Leo <
paul@dataphilesconsulting.com>:
...

> The reason I am posting here instead of TortoiseSVN is I would like to
> know whether it would be safer to have folks just do a new checkout from
> new server once old server is shutdown, (and diff folders if needed)
> instead of trying relocate, or should I have them edit the wc.db and
> replace or try and change the uuid on the new server to match the old one.
>

Since you use TortoiseSVN, the other option would be to remove the .svn
folder and do a new checkout in the same directory. TortoiseSVN is quite
nice that it picks up the existing files and says "Versioned" on them and
you can usually continue as before. The command line client seems to mark
the existing files as "Conflict" and require a lot of manual work to
resolve. Of course, test it first but it might be an easier solution than
manually carrying over any changes to the new working copy.

I'd avoid editing wc.db - it usually works but I'd be careful asking
endusers to do it.

Kind regards,
Daniel

Re: Migration from CentOS 7, Subversion 1.94 to Ubuntu 24.04, SVN 1.14.3

[Andreas Stieger]

On 2024-06-18 23:19, Paul Leo wrote:

If I try a relocate in TortoiseSVN, I get an error saying the uuid of
the new server is different than the WC of the local repo.   I presume
this is because of the DNS name change.



No, this is because the UUID is different.



I've done some searching and have followed a suggestion and edited the
wc.db and replaced old server uuid with new server uuid, tried the
relocate command again and things seem to be working and pointing to
new server.



No, see "svnadmin help setuuid"



I also know that doing a new checkout from the new server may be the
simplest solution. But perhaps some folks will not commit all of their
changes before switchover because they are not ready.



Make the old one read-only via a pre-commit hook if you can.


Andreas

Re: Migration from CentOS 7, Subversion 1.94 to Ubuntu 24.04, SVN 1.14.3

[Paul Leo]

Thanks Ryan.  I guess I can't believe everything on the internet, where 
I got the DNS name story


The commands used to create and sync the repo were:

svnsync initialize file:///srv/svn_repos/ibis/main 
https://svn.ibisph.org/svn/main


svnsync synchronize file:///srv/svn_repos/ibis/main 
https://svn.ibisph.org/svn/main


I didn't receive any errors during the sync

So I assumed that the uuid would be the same but they are different.

Perhaps the safest way for folks to switch would be to create a new folder

Checkout from new server

Diff with old folder from old server, and bring over any changes folks 
want and then commit to new server.


Thanks

On 6/18/2024 4:05 PM, Ryan Carsten Schmidt wrote:

On Jun 18, 2024, at 16:19, Paul Leo wrote:

If I try a relocate in TortoiseSVN, I get an error saying the uuid of the new 
server is different than the WC of the local repo.   I presume this is because 
of the DNS name change.

The DNS name has nothing to do with the UUID.

If the new repository is *identical* to the old repository (all of the old 
repository's revisions were copied and they have exactly the same contents) 
then you will want the UUIDs to be the same so that you can relocate existing 
working copies. The old repository's UUID is automatically copied to the new 
repository when you import a dumpfile into a newly created repository unless 
you use a command line flag to tell it to generate a new UUID.

On the other hand, if the new repository differs at all from the old one (for 
example you filtered out revisions or you imported the dumpfile into an 
existing non-empty repository) then the new repository UUID must be different 
and relocation is not possible and new working copies must be checked out.

Re: Migration from CentOS 7, Subversion 1.94 to Ubuntu 24.04, SVN 1.14.3

[Ryan Carsten Schmidt]

On Jun 18, 2024, at 16:19, Paul Leo wrote:
> 
> If I try a relocate in TortoiseSVN, I get an error saying the uuid of the new 
> server is different than the WC of the local repo.   I presume this is 
> because of the DNS name change.

The DNS name has nothing to do with the UUID.

If the new repository is *identical* to the old repository (all of the old 
repository's revisions were copied and they have exactly the same contents) 
then you will want the UUIDs to be the same so that you can relocate existing 
working copies. The old repository's UUID is automatically copied to the new 
repository when you import a dumpfile into a newly created repository unless 
you use a command line flag to tell it to generate a new UUID.

On the other hand, if the new repository differs at all from the old one (for 
example you filtered out revisions or you imported the dumpfile into an 
existing non-empty repository) then the new repository UUID must be different 
and relocation is not possible and new working copies must be checked out.

Re: Migration from CentOS 7, Subversion 1.94 to Ubuntu 24.04, SVN 1.14.3

[Paul Leo]

Once again thanks for all your past help

The new repository is up and running. But we haven't cut over yet.

I have asked folks to commit all changes that they would like included 
in new repo.


I'm using svnsync multiple times per day, with no issues.

There's a good chance that DNS name may not be able to stay the same.

TortoiseSvn is used almost exclusively for commits. and checkouts.

If I try a relocate in TortoiseSVN, I get an error saying the uuid of 
the new server is different than the WC of the local repo.   I presume 
this is because of the DNS name change.


I've done some searching and have followed a suggestion and edited the 
wc.db and replaced old server uuid with new server uuid, tried the 
relocate command again and things seem to be working and pointing to new 
server.


I also know that doing a new checkout from the new server may be the 
simplest solution. But perhaps some folks will not commit all of their 
changes before switchover because they are not ready.


The reason I am posting here instead of TortoiseSVN is I would like to 
know whether it would be safer to have folks just do a new checkout from 
new server once old server is shutdown, (and diff folders if needed) 
instead of trying relocate, or should I have them edit the wc.db and 
replace or try and change the uuid on the new server to match the old one.


I've done some reading in the SVN-redbook, but am concerned that perhaps 
there are things that I may be missing because the redbook may be out of 
date.


I've also read of some issues of changing uuid on server, so if that is 
what should be done, I would like specific instructions/suggestions.


Thanks,

Paul

On 6/7/2024 10:17 AM, Paul Leo wrote:


Tak Daniel.

Appreciate the detailed response.  I have asked for the two hooks that 
seemed to be copied from the templates.


If the dump doesn't work, I may have them try and tar up the whole 
repo directory.


I do have the auth tables, and will try them once repo is up and 
running, otherwise, I will create new user/passwords.  The community 
is small enough so that this should not be an issue.


On 6/7/2024 2:16 AM, Daniel Sahlberg wrote:
Den tors 6 juni 2024 kl 21:40 skrev Paul Leo 
:


We need to migrate an SVN repository from CentOS 7, Subversion
1.94 to
Ubuntu 24.04, SVN 1.14.3.

We don't have any login access to the current server.

The current hosting server plans to perform an SVN dump of the
repository, and make it available through something like Google
Drive.

We would obtain the dump file and then use svnadmin load,
importing the
repository.


As others have already pointed out svnadmin dump/load or svnrdump are 
the main candidates. Another option is to have your hosting provider 
pack the repository folder in its entirety (to a tar.gz) which you 
could unpack on the new server and use as-is.



There are only a few hooks that are currently used.  The main one
being
to force a commit message when committing.


Although the dump file does NOT contain any hook scripts. These need 
to be extracted from the [/path/to/repo]/hooks directory on the 
server. If you don't have access to the server yourself (and the 
hosting provider doesn't have a web interface to manage the hook 
scripts) you need to ask them to copy the scripts manually. (If your 
hosing provider choose to pack the complete repository folder the 
hooks are of course included).



We will use Apache httpd and basic authentication for committing to
repository, as in done currently


The authentication (login) and authorization (permissions) are not 
included in the dump file either. If you want to keep the 
username/passwords the hosting provider need to give you these files 
as well (path and filename depends on the setup in Apache httpd).



We would change DNS to new server IP.


I assume you mean you use a DNS entry 
(https://svn.example.com/repos/.. 
.) which will be updated. In this 
case you should not need to do anything. If you change some part of 
the URL (either new hostname, adding SSL/TLS or the path to the 
repositories) you need to run


svn relocate [new_url]

in each working copy.


I've read through the svnbook, and the above seems plausible.

I am just wondering if anyone has some guidance and suggestions,
since
we are making a significant jump to newer version of SVN.


There should be no major difference.


Thanks for your help


Kind regards,
Daniel

Re: SVN over NFS/CIFS (Windows client to Linux server)

[Daniel Sahlberg]

Den tis 18 juni 2024 kl 17:49 skrev Johnston, Tim <
tim.johns...@christiedigital.com>:

> We are using SVN 1.7 repositories which are checked out to a Linux file
> server. Users access their files via TortoiseSVN (1.7.15, which is also
> built against SVN 1.7.x), either via CIFS or NFS.
>

That is a really old version, with an equally old version of SQLite.


>
> When accessing via CIFS (with the Linux side serving via Samba), we
> occasionally encounter SQLite database corruption. My understanding is that
> this is caused by differences between the Windows and POSIX locking
> implementations (inside libsvn).
>

I'm not sure if it is Subversion or SQLite that is having the most problems
but general wisdom is to not store a working copy on a network share.


>
> When accessing via the official Windows NFS client (talking to a Linux NFS
> server), we are unable to even check out a repository via TortoiseSVN. It
> fails immediately with a locking error.
>
> I find it very difficult to search for this issue, partly because SVN has
> an unrelated "file locking" feature, and partly because users have posted
> about a number of other simpler SQLite corruption issues with SVN..
>
> So my question is this: what is the current state of SVN clients on
> Windows, accessing a Linux file share, with respect to file locking /
> SQLite etc?
> Are there options for this problem with newer Windows (Tortoise)SVN client
> versions? Or is this problem still the same in the newest versions?
>

I don't think any significant work has been done towards supporting working
copies on network shares. Subversion relies on proper file locking and if
this fails (which I assume is the cause of your trouble) then all bets are
off.

SQLite goes quite far in recommending to use another database engine if
over-the-network functionality is required:
https://www.sqlite.org/useovernet.html

These are the two FAQ items I can find mentioning problems storing a
working copy / sqlite database on a network share:
https://tortoisesvn.net/faq.html#wconshare
https://www.sqlite.org/faq.html#q5

Our own FAQ suggests that storing a working copy on an NFS share should be
fine, but I presume the Windows NFS client is not as well behaved as Unix
NFS clients.
https://subversion.apache.org/faq.html#nfs


>
> Any recommendations would be appreciated!
>

Why do you need to store the working copy on a network share? Can you
adjust your workflow to make sure every user has their own working copy,
stored on local disk?

Kind regards,
Daniel

Re: Loss by accident, clean up unversioned files

[Bo Berglund]

On Fri, 14 Jun 2024 20:40:40 +0530, Ayyanar Raja  wrote:

>Dear Andreas,
>
>Why it is happened. What is the root actually?
>
>In future, Google Groups will be closed completely, where is our forum
>running now ?

This is not a forum, it is a mail list


-- 
Bo Berglund
Developer in Sweden

Re: Loss by accident, clean up unversioned files

[Daniel Sahlberg]

You are discussing this in the wrong forum. This is for the Subversion
command line client (and the related libraries).

Your question belong in the TortoiseSVN Google groups. Hopefully someone
will pick it up there. I'm planning to look at it - but at the moment I'm
busy with other stuff.

Kind regards,
Daniel

Den fre 14 juni 2024 kl 17:15 skrev Ayyanar Raja :

> Dear Andreas,
>
> Why it is happened. What is the root actually?
>

> In future, Google Groups will be closed completely, where is our forum
> running now ?
>
> --
> Best Regards,
> Ayyanar Raja
> Mobile: +91-7639269672
> Email: rsa2...@gmail.com
>
> On Fri, 14 Jun 2024, 8:37 pm Andreas Stieger, 
> wrote:
>
>> On 2024-06-14 16:52, Ayyanar Raja wrote:
>>
>> Is there anyway I can recover files ?
>>
>>
>> Your files are gone.
>>
>> Andreas
>>
>>
>>

Re: Loss by accident, clean up unversioned files

[Ayyanar Raja]

Dear Andreas,

Why it is happened. What is the root actually?

In future, Google Groups will be closed completely, where is our forum
running now ?

--
Best Regards,
Ayyanar Raja
Mobile: +91-7639269672
Email: rsa2...@gmail.com

On Fri, 14 Jun 2024, 8:37 pm Andreas Stieger, 
wrote:

> On 2024-06-14 16:52, Ayyanar Raja wrote:
>
> Is there anyway I can recover files ?
>
>
> Your files are gone.
>
> Andreas
>
>
>

Re: Loss by accident, clean up unversioned files

[Andreas Stieger]

  
  
On 2024-06-14 16:52, Ayyanar Raja
  wrote:


  
  
Is there anyway I can recover files ?
  



Your files are gone.
Andreas



  

Re: Loss by accident, clean up unversioned files

[Ayyanar Raja]

Is there anyway I can recover files ?

It is happened by unknowingly, It is not intentional to do so.

--
Best Regards,
Ayyanar Raja
Mobile: +91-7639269672
Email: rsa2...@gmail.com

On Fri, 14 Jun 2024, 7:54 pm Nico Kadel-Garcia,  wrote:

> On Fri, Jun 14, 2024 at 6:38 AM Ayyanar Raja  wrote:
> >
> > Hi Team,
> >
> > As per the below mail, I've unknowingly deleted the unversioned files.
> How to recover them?
> >
> > Why is this not yet fixed ?
> >
> > --
> > Best Regards,
> > Ayyanar Raja
> > Mobile: +91-7639269672
> > Email: rsa2...@gmail.com
>
> "Stop doing that". Changes to system config files should be in source
> control *first*, not after the fact. I've had that argument with
> various people. It can create a lot of bulk in Subversion systems,
> since there is no way to completely expunge extraneous or discarded
> work, but it's much safer to pull changes from a development branch,
> not edit locally and "commit when it's done".
>

Re: Loss by accident, clean up unversioned files

[Nico Kadel-Garcia]

On Fri, Jun 14, 2024 at 6:38 AM Ayyanar Raja  wrote:
>
> Hi Team,
>
> As per the below mail, I've unknowingly deleted the unversioned files. How to 
> recover them?
>
> Why is this not yet fixed ?
>
> --
> Best Regards,
> Ayyanar Raja
> Mobile: +91-7639269672
> Email: rsa2...@gmail.com

"Stop doing that". Changes to system config files should be in source
control *first*, not after the fact. I've had that argument with
various people. It can create a lot of bulk in Subversion systems,
since there is no way to completely expunge extraneous or discarded
work, but it's much safer to pull changes from a development branch,
not edit locally and "commit when it's done".

Re: [External] : Re: Fwd: Loss by accident, clean up unversioned files

[Trent Fisher via users]

On 6/14/2024 9:13 AM, Ayyanar Raja wrote:


NoDear Andreas,

Thanks for your reply. I'm looking forward your support on this to 
recover files.


Actually I'm new to SVN. When I'm trying to deleted SVN commited file, 
I unknowingly cleaned up unversioned files.


But, More than those SVN file, I need my unversioned files.


> Why is this not yet fixed ?

I raised this question for the Dev team.


But this is outside the scope of Subversion, or really, any version 
control system.  I have worked with nearly a dozen version control 
systems over the years, and not one of them preserve unversioned files.  
And in the case of Mercurial and Git, even checked in files could be 
lost if they haven't been pushed and the workspace gets damaged/erased.  
What you are describing would be an OS/filesystem feature where deleted 
files are preserved someplace (which is really a sort of version control 
system in disguise)


If something is important, it should be checked in.  If you're not 
checking in because you don't want others to see, or be affected by, 
incomplete work, then use a branch.  Check in early and check in often!


I often say that there are three kinds of things in the world: things 
checked into version control, things generated from things in version 
control, and garbage.

Re: Fwd: Loss by accident, clean up unversioned files

[Ayyanar Raja]

NoDear Andreas,

Thanks for your reply. I'm looking forward your support on this to recover
files.

Actually I'm new to SVN. When I'm trying to deleted SVN commited file, I
unknowingly cleaned up unversioned files.

But, More than those SVN file, I need my unversioned files.


> Why is this not yet fixed ?

I raised this question for the Dev team.


--
Best Regards,
Ayyanar Raja
Mobile: +91-7639269672
Email: rsa2...@gmail.com

On Fri, 14 Jun 2024, 6:25 pm Andreas Stieger, 
wrote:

>
> On 2024-06-14 12:30, Ayyanar Raja wrote:
> > On Saturday, July 10, 2021 at 5:22:36 PM UTC+5:30 Jose Gaspar wrote:
> >>
> >> Done, by accident, a clean up including unversioned files.
> >> TortoiseSVN indicates deleted unversioned files can be recovered from
> >> the recycle bin:
> >>
> >>
> https://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug-rename.html
> >>
> >
> > As per the below mail, I've unknowingly deleted the unversioned files.
> > How to recover them?
>
>
> Subversion, by design, does not version unversioned files. Requesting to
> delete them will do exactly that. If they should be permanently
> versioned, you should commit them. Read about branches, in particular
> feature branches, to create a permanent record of intermediate work
> inside the repository.
>
> The TSVN extension for the recycle bin functionality is custom to them.
> I looked into adding API support for this via the Windows API/ XDG where
> supported but this would go beyond the tool.
>
> > Why is this not yet fixed ?
>
> I believe that desktop backup, and point-in-time recovery for
> uncommitted work are out of scope for Subversion. The recommend method
> is to work on branches.
>
> Andreas
>
>
>
>
>

Re: Fwd: Loss by accident, clean up unversioned files

[Andreas Stieger]

On 2024-06-14 12:30, Ayyanar Raja wrote:

On Saturday, July 10, 2021 at 5:22:36 PM UTC+5:30 Jose Gaspar wrote:


Done, by accident, a clean up including unversioned files.
TortoiseSVN indicates deleted unversioned files can be recovered from
the recycle bin:

https://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug-rename.html



As per the below mail, I've unknowingly deleted the unversioned files.
How to recover them?



Subversion, by design, does not version unversioned files. Requesting to
delete them will do exactly that. If they should be permanently
versioned, you should commit them. Read about branches, in particular
feature branches, to create a permanent record of intermediate work
inside the repository.

The TSVN extension for the recycle bin functionality is custom to them.
I looked into adding API support for this via the Windows API/ XDG where
supported but this would go beyond the tool.


Why is this not yet fixed ?


I believe that desktop backup, and point-in-time recovery for
uncommitted work are out of scope for Subversion. The recommend method
is to work on branches.

Andreas

Re: Migration from CentOS 7, Subversion 1.94 to Ubuntu 24.04, SVN 1.14.3

[Paul Leo]

Tak Daniel.

Appreciate the detailed response.  I have asked for the two hooks that 
seemed to be copied from the templates.


If the dump doesn't work, I may have them try and tar up the whole repo 
directory.


I do have the auth tables, and will try them once repo is up and 
running, otherwise, I will create new user/passwords.  The community is 
small enough so that this should not be an issue.


On 6/7/2024 2:16 AM, Daniel Sahlberg wrote:
Den tors 6 juni 2024 kl 21:40 skrev Paul Leo 
:


We need to migrate an SVN repository from CentOS 7, Subversion
1.94 to
Ubuntu 24.04, SVN 1.14.3.

We don't have any login access to the current server.

The current hosting server plans to perform an SVN dump of the
repository, and make it available through something like Google Drive.

We would obtain the dump file and then use svnadmin load,
importing the
repository.


As others have already pointed out svnadmin dump/load or svnrdump are 
the main candidates. Another option is to have your hosting provider 
pack the repository folder in its entirety (to a tar.gz) which you 
could unpack on the new server and use as-is.



There are only a few hooks that are currently used.  The main one
being
to force a commit message when committing.


Although the dump file does NOT contain any hook scripts. These need 
to be extracted from the [/path/to/repo]/hooks directory on the 
server. If you don't have access to the server yourself (and the 
hosting provider doesn't have a web interface to manage the hook 
scripts) you need to ask them to copy the scripts manually. (If your 
hosing provider choose to pack the complete repository folder the 
hooks are of course included).



We will use Apache httpd and basic authentication for committing to
repository, as in done currently


The authentication (login) and authorization (permissions) are not 
included in the dump file either. If you want to keep the 
username/passwords the hosting provider need to give you these files 
as well (path and filename depends on the setup in Apache httpd).



We would change DNS to new server IP.


I assume you mean you use a DNS entry 
(https://svn.example.com/repos/.. .) 
which will be updated. In this case you should not need to do 
anything. If you change some part of the URL (either new hostname, 
adding SSL/TLS or the path to the repositories) you need to run


svn relocate [new_url]

in each working copy.


I've read through the svnbook, and the above seems plausible.

I am just wondering if anyone has some guidance and suggestions,
since
we are making a significant jump to newer version of SVN.


There should be no major difference.


Thanks for your help


Kind regards,
Daniel

Re: Migration from CentOS 7, Subversion 1.94 to Ubuntu 24.04, SVN 1.14.3

[Paul Leo]

List - Thanks for all previous replies

Nico,

I can assure you that the work is legitimate.   I support a consortium 
of 8 or so state health departments. They all use an application called 
IBIS (here's one version https://ibis.doh.nm.gov/).


I am working with Utah Dept of HHS, and Hawaii Data Warehouse who 
contracts with the Hawaii Dept of Health. Currently the content is 
stored in the SVN repository hosted in UT.  That server is managed by UT 
Dept of HHS, and because of state security I am not permitted to have 
login access to that server.  That server is scheduled to be turned of 
at the end of this month. Hawaii has offered to host the repository. So 
I am working with them to set it up.   UT proposed using the dump file 
which they would share via some network cloud storage.


I had asked the about svnsync, and am concerned that they may have some 
kind of high bandwidth or large "downloads" detection. I have not heard 
back from them so I am attempting to use what they propose.


I should be able to try loading this weekend, and see whether or not the 
load chokes.  If it does I will work with UT for other ways to migrate.


Thanks for you warning about large repos, and your suggestion.

On 6/7/2024 3:15 AM, Nico Kadel-Garcia wrote:

On Fri, Jun 7, 2024 at 1:31 AM Lorenz via users
 wrote:

Paul Leo wrote:


We need to migrate an SVN repository from CentOS 7, Subversion 1.94 to
Ubuntu 24.04, SVN 1.14.3.

We don't have any login access to the current server.

The current hosting server plans to perform an SVN dump of the
repository, and make it available through something like Google Drive.

We would obtain the dump file and then use svnadmin load, importing the
repository.

There are only a few hooks that are currently used.  The main one being
to force a commit message when committing.

We will use Apache httpd and basic authentication for committing to
repository, as in done currently

We would change DNS to new server IP.


"Missing login access" is not the same as "missing bacup access". If
you can save the SSH hostkeys, and the TLS certificates which may be
on the host for transfer to the new host, you probably want to do so
to keep transfers consistent and avoid arguments about changed host
specific keys. If you don't have backup access why are you
responsible for this work? And are you planning a man-in-the-middle
replication and replacement?

If the work is legitimate, might I suggest using "svnsync" for the
transfer, rather than svnad,om dump and restore? It won't preserve all
your locally modified post or pre commit hooks, but what you describe
is a simple setup, oddnesses done to those scripts should be recorded
as Infrastructurre As Code fpr a production system.

Unfortunately, if the repo has gotten too large over the years,
svnadmin duump and restore, and svnsync, will choke to death before
completion. This is what happens with the primary Subversion source
repo, which can no longer be reliably replicated.




I've read through the svnbook, and the above seems plausible.

I am just wondering if anyone has some guidance and suggestions, since
we are making a significant jump to newer version of SVN.

Thanks for your help


You might want to retain the repository UUID, otherwise you would need
to re-checkout your working copies
--

Lorenz

Re: Migration from CentOS 7, Subversion 1.94 to Ubuntu 24.04, SVN 1.14.3

[Nico Kadel-Garcia]

On Fri, Jun 7, 2024 at 1:31 AM Lorenz via users
 wrote:
>
> Paul Leo wrote:
>
> >We need to migrate an SVN repository from CentOS 7, Subversion 1.94 to
> >Ubuntu 24.04, SVN 1.14.3.
> >
> >We don't have any login access to the current server.
> >
> >The current hosting server plans to perform an SVN dump of the
> >repository, and make it available through something like Google Drive.
> >
> >We would obtain the dump file and then use svnadmin load, importing the
> >repository.
> >
> >There are only a few hooks that are currently used.  The main one being
> >to force a commit message when committing.
> >
> >We will use Apache httpd and basic authentication for committing to
> >repository, as in done currently
> >
> >We would change DNS to new server IP.


"Missing login access" is not the same as "missing bacup access". If
you can save the SSH hostkeys, and the TLS certificates which may be
on the host for transfer to the new host, you probably want to do so
to keep transfers consistent and avoid arguments about changed host
specific keys. If you don't have backup access why are you
responsible for this work? And are you planning a man-in-the-middle
replication and replacement?

If the work is legitimate, might I suggest using "svnsync" for the
transfer, rather than svnad,om dump and restore? It won't preserve all
your locally modified post or pre commit hooks, but what you describe
is a simple setup, oddnesses done to those scripts should be recorded
as Infrastructurre As Code fpr a production system.

Unfortunately, if the repo has gotten too large over the years,
svnadmin duump and restore, and svnsync, will choke to death before
completion. This is what happens with the primary Subversion source
repo, which can no longer be reliably replicated.



> >
> >I've read through the svnbook, and the above seems plausible.
> >
> >I am just wondering if anyone has some guidance and suggestions, since
> >we are making a significant jump to newer version of SVN.
> >
> >Thanks for your help
> >
>
> You might want to retain the repository UUID, otherwise you would need
> to re-checkout your working copies
> --
>
> Lorenz
>

Re: Migration from CentOS 7, Subversion 1.94 to Ubuntu 24.04, SVN 1.14.3

[Daniel Sahlberg]

Den tors 6 juni 2024 kl 21:40 skrev Paul Leo <
paul@dataphilesconsulting.com>:

> We need to migrate an SVN repository from CentOS 7, Subversion 1.94 to
> Ubuntu 24.04, SVN 1.14.3.
>
> We don't have any login access to the current server.
>
> The current hosting server plans to perform an SVN dump of the
> repository, and make it available through something like Google Drive.
>
> We would obtain the dump file and then use svnadmin load, importing the
> repository.
>

As others have already pointed out svnadmin dump/load or svnrdump are the
main candidates. Another option is to have your hosting provider pack the
repository folder in its entirety (to a tar.gz) which you could unpack on
the new server and use as-is.


>
> There are only a few hooks that are currently used.  The main one being
> to force a commit message when committing.
>

Although the dump file does NOT contain any hook scripts. These need to be
extracted from the [/path/to/repo]/hooks directory on the server. If you
don't have access to the server yourself (and the hosting provider doesn't
have a web interface to manage the hook scripts) you need to ask them to
copy the scripts manually. (If your hosing provider choose to pack the
complete repository folder the hooks are of course included).


> We will use Apache httpd and basic authentication for committing to
> repository, as in done currently
>

The authentication (login) and authorization (permissions) are not included
in the dump file either. If you want to keep the username/passwords the
hosting provider need to give you these files as well (path and filename
depends on the setup in Apache httpd).


>
> We would change DNS to new server IP.
>

I assume you mean you use a DNS entry (https://svn.example.com/repos/...)
which will be updated. In this case you should not need to do anything. If
you change some part of the URL (either new hostname, adding SSL/TLS or the
path to the repositories) you need to run

svn relocate [new_url]

in each working copy.


> I've read through the svnbook, and the above seems plausible.
>
> I am just wondering if anyone has some guidance and suggestions, since
> we are making a significant jump to newer version of SVN.
>

There should be no major difference.


>
> Thanks for your help
>
>
Kind regards,
Daniel

Re: Migration from CentOS 7, Subversion 1.94 to Ubuntu 24.04, SVN 1.14.3

[Andreas Stieger]

Hello,

On 2024-06-06 21:40, Paul Leo wrote:

[...] migrate an SVN repository from CentOS 7, Subversion 1.94 to
Ubuntu 24.04, SVN 1.14.3.
[...]



The current hosting server plans to perform an SVN dump of the
repository, and make it available through something like Google Drive.
We would obtain the dump file and then use svnadmin load, importing
the repository.


No cooperation from the hosting provider needed. See "svnrdump help
dump", and yes this does exactly what you need. Assuming you don't have
any path based access controls this is the same as a local dump.


I am just wondering if anyone has some guidance and suggestions, since
we are making a significant jump to newer version of SVN.


dump/load is the right thing to do in this case.

Andreas

Re: Migration from CentOS 7, Subversion 1.94 to Ubuntu 24.04, SVN 1.14.3

[Ryan Carsten Schmidt]

On Jun 7, 2024, at 00:32, Lorenz via users wrote:
> 
> You might want to retain the repository UUID, otherwise you would need
> to re-checkout your working copies

Loading the dumpfile into a new repository will preserve the UUID unless you 
tell it not to. 

Re: Migration from CentOS 7, Subversion 1.94 to Ubuntu 24.04, SVN 1.14.3

[Lorenz via users]

Paul Leo wrote:

>We need to migrate an SVN repository from CentOS 7, Subversion 1.94 to 
>Ubuntu 24.04, SVN 1.14.3.
>
>We don't have any login access to the current server.
>
>The current hosting server plans to perform an SVN dump of the 
>repository, and make it available through something like Google Drive.
>
>We would obtain the dump file and then use svnadmin load, importing the 
>repository.
>
>There are only a few hooks that are currently used.  The main one being 
>to force a commit message when committing.
>
>We will use Apache httpd and basic authentication for committing to 
>repository, as in done currently
>
>We would change DNS to new server IP.
>
>I've read through the svnbook, and the above seems plausible.
>
>I am just wondering if anyone has some guidance and suggestions, since 
>we are making a significant jump to newer version of SVN.
>
>Thanks for your help
>

You might want to retain the repository UUID, otherwise you would need
to re-checkout your working copies
-- 

Lorenz

Re: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Daniel Sahlberg]

Den mån 27 maj 2024 kl 14:18 skrev Johan Corveleyn :

> On Sat, May 25, 2024 at 12:12 AM Williams, James P. {Jim}
> (JSC-CD4)[KBR Wyle Services, LLC] via users
>  wrote:
> >
> > > Den lör 11 maj 2024 kl 03:00 skrev Williams, James P. {Jim}
> (JSC-CD4)[KBR Wyle Services, LLC] via users :
> >
> > > You previously mentioned Subversion 1.14.1, is that on the server or
> on the client?
> >
> > I'm using 1.14.1 on both the client and server.
> >
> > > Still it would be interesting to compare just to rule out a problem
> within the repository. You can use svnserve directly or tunneled over SSH,
> see the Subversion book:
> >
> > With svnserve 1.14.1, I see no problems.  Checkouts complete every
> time.  I'm not sure what to conclude about that.  It's a different
> protocol, so it doesn't necessarily exonerate the client or the network.
> >
> > > >   #0  epoll_wait   /usr/lib64/libc.so.6
> >
> > > Waiting for a reply from the server ... ?
> >
> > Yeah, that'd be my guess.  When the hang occurs, I've got about 90% of
> the working copy checked out.  I expect the client is waiting for more
> bytes to arrive on the socket.
> >
> > > Do you see any activity on the server (CPU / disk) during this time?
> >
> > The server is well-behaved throughout all of my tests.  It shows no CPU
> spike or log messages hinting that it's noticed a problem.
>
> That's why my bet is still on "something between client and server"
> (proxy, reverse-proxy, security scanning soft, ...) that messes with
> the network transfer (http or https). That would explain the symptoms
> you're seeing (client hangs waiting for network (and sometimes
> crashes), server has nothing to do and doesn't report anything
> special).
>

I agree with Johan and I understand it might be hard to nail down the
actual issue.

I don't think I have asked this before:
- Can you log in to the server and do an svn checkout https://localhost/[...]
locally and does this succeed? You might have to update the Apache HTTPD
configuration to allow the vhost to reply to "localhost" (or you could add
the server name to the local hosts file pointing to 127.0.0.1 and do a
checkout of https://[server]/[url]). What I'd like to accomplish is a
checkout that doesn't leave the machine. Does this make a difference?

Kind regards,
Daniel

Re: GUI interface to Subversion via web browser?

[Kris Deugau]

Johan Corveleyn wrote:

What lots of people these days are looking for (myself included) is a
modern "Code Forge" [1][2][3], like GitHub/Lab/... or like the Forgejo
project [4] with its cloud-hosted platform Codeberg [5], but then for
Subversion.

I'd like a modern web interface (hostable on-premise or in the cloud)
that includes:
- Version control repositories (and management thereof)
- Online viewing, searching, diffing, ... (like ViewVC)
- Online editing, committing directly from the web interface
- Ability to manage patches aka pull requests
- Mailing lists and Forums
- Notification system (with ability to individually configure "watch" patterns)
- Issue tracker
- Code reviews
- Wiki
- General (plugable) "Actions" framework
- CI system with buildagents / bots
- Artifact repository
- Enterprise level user management
- ...
- Also accessible from mobile devices of course

Oh, and if possible it should flexibly integrate with external systems
that may already be present in your environment, like if you have a
JIRA issue tracker or wiki or ... you would want to integrate that one
instead of the "default / reference" implementation.


Trac?  https://trac.edgewall.org

I don't think it ticks all of your boxes, but it hits most of them.

-kgd

Re: Re: [EXTERNAL] Re: Moved file resolution fails

[Nathan Hartman]

On Thu, May 30, 2024 at 5:09 PM Sands, Daniel N. via users <
users@subversion.apache.org> wrote:

>
> On 2024/02/15 17:42:59 "Sands, Daniel N. via users" wrote:
> > On Thu, 2024-02-15 at 08:55 -0500, Nico Kadel-Garcia wrote:
> > > [You don't often get email from nka...@gmail.com. Learn why this is
> > > important at https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > On Wed, Feb 14, 2024 at 4:59 PM Sands, Daniel N. via users
> > >  wrote:
> > >
> > > > So lesson learned:  Always make a pristine copy of the trunk
> before
> > > > making ANY changes, so that there is a revision to fall back on
> > > > where
> > > > the two branches exactly match.
> > >
> > > That's what tags are for!
> >
> > I'd heard of tagging but wasn't sure how to do it since I'm not
> > responsible for the releases... but it looks like you tag by using
> the
> > copy command.  Even worse, the text under "complex tagging" shows
> > copying your working directory to a new repo, which is what breaks
> the
> > file move/rename detection.
> >
> > On a further note, my real repo has 260 moves due to source tree
> > restructuring.  There were 290 deletions.  The current move detection
> > algorithm is an O(n^2) search to find all moves, where it ends up
> > querying the SVN server 260*290 times for merge info, per file
> > conflict.  Perhaps it would be a good cost savings to cache the merge
> > info for each file during the search, so that there are O(n) trips to
> > the server and everything else is resolved locally?
> >
> I came up with a patch for this issue.  It cuts the resolve time down
> from literal hours in my case, to less than a minute.  I can't say it's
> production ready, but it's a template at least.
>
> It attacks the core of the problem, where every time it comes up with a
> candidate pair to check, it downloads the history from the repo on each
> file.  This happened for the same left-side file hundreds of times
> while it tried each candidate right-side file.
>
> The patch leaves in (commented-out) printfs to show the problem in
> action.  The other part is, now that I have to persist data as long as
> the client context, do the temporary results pools get used for
> anything at all?  Finally, there is one change to a public API that
> would need to be fixed.
>
> >
> >
>


Hi,

Any chance you can send your patch uncompressed, with an extension like
".patch.txt"?

Thanks,

Nathan

RE: Re: [EXTERNAL] Re: Moved file resolution fails

[Sands, Daniel N. via users]

On 2024/02/15 17:42:59 "Sands, Daniel N. via users" wrote:
> On Thu, 2024-02-15 at 08:55 -0500, Nico Kadel-Garcia wrote:
> > [You don't often get email from nka...@gmail.com. Learn why this is
> > important at https://aka.ms/LearnAboutSenderIdentification ]
> > 
> > On Wed, Feb 14, 2024 at 4:59 PM Sands, Daniel N. via users
> >  wrote:
> > 
> > > So lesson learned:  Always make a pristine copy of the trunk
before
> > > making ANY changes, so that there is a revision to fall back on
> > > where
> > > the two branches exactly match.
> > 
> > That's what tags are for!
> 
> I'd heard of tagging but wasn't sure how to do it since I'm not
> responsible for the releases... but it looks like you tag by using
the
> copy command.  Even worse, the text under "complex tagging" shows
> copying your working directory to a new repo, which is what breaks
the
> file move/rename detection.
> 
> On a further note, my real repo has 260 moves due to source tree
> restructuring.  There were 290 deletions.  The current move detection
> algorithm is an O(n^2) search to find all moves, where it ends up
> querying the SVN server 260*290 times for merge info, per file
> conflict.  Perhaps it would be a good cost savings to cache the merge
> info for each file during the search, so that there are O(n) trips to
> the server and everything else is resolved locally?
> 
I came up with a patch for this issue.  It cuts the resolve time down
from literal hours in my case, to less than a minute.  I can't say it's
production ready, but it's a template at least.

It attacks the core of the problem, where every time it comes up with a
candidate pair to check, it downloads the history from the repo on each
file.  This happened for the same left-side file hundreds of times
while it tried each candidate right-side file.

The patch leaves in (commented-out) printfs to show the problem in
action.  The other part is, now that I have to persist data as long as
the client context, do the temporary results pools get used for
anything at all?  Finally, there is one change to a public API that
would need to be fixed.

> 
> 



svn-1.14-3.cache.diff.xz
Description: svn-1.14-3.cache.diff.xz

Re: GUI interface to Subversion via web browser?

[Bo Berglund]

On Wed, 29 May 2024 10:54:27 -, Michael Osipov  wrote:

>For other WebSVN issues, please raise withe GitHub project, I will respond.

Done, first post: https://github.com/websvnphp/websvn/issues/220


-- 
Bo Berglund
Developer in Sweden

Re: GUI interface to Subversion via web browser?

[Michael Osipov]

On 2024/05/26 19:57:46 Bo Berglund wrote:
> On Sun, 26 May 2024 10:24:27 -, Michael Osipov  
> wrote:
> 
> >> WebSVN is still actively maintained (version 2.8.4 was released 2 months 
> >> ago) and offers the features you're looking for (view files, logs and 
> >> diffs) and more.
> >> 
> >> I'm not aware of any screenshots, but installing it for evaluation 
> >> purposes is reasonably straightforward.
> >
> >More or less solve maintainer of WebSVN here. I try to keep it alive with 
> >fixes and small improvements for the entire community. Thought, I cannot 
> >compare it to ViewVC, never used.
> >
> >> For small to medium-scale projects, I find it a really helpful addition 
> >> to the Subversion server. For large-scale projects with more than a 
> >> thousand branches or tags, performance will become an issue.
> >
> >Yes, that is a long standing problem [1] I'd like to solve, but cannot ATM 
> >due to lack of time and knowledge in that area.
> >
> >Michael
> 
> Thanks for the explanation!
> 
> Our repository contains a fair number of projects organized as:
> "project type"/"project name"/trunk,branches,tags
> 
> The "project type" level consists of 11 named type directories.
> Below each type are the actual project directories with the project name as 
> the
> dir name.
> And within each project we start with trunk-tags-branches dirs until we get to
> the actual data.
> 
> There ia usually just 1 or 2 persons working on each project.
> 
> And the number of commits are rather limited as well as the tags and branches.
> The latter are mostly non-existing or just a handful.
> 
> My problem with ApacheSVN interface:
> 
> With the Apache SVN installation where I keep the backups (using svnsync) it 
> is
> not possible to display the top level so the project types can be shown and
> stepped into.
> 
> I just get a "Forbidden" error if I try to use the URL that should get me to 
> the
> top.
> 
> If I know the top level name I can get to a navigable list and drill down from
> there.
> 
> So all other levels I can navigate with the web browser, but there is not much
> one can do there, for instance viewing the log message tree for a file etc.
> 
> And if I click a file in the list it will be downloaded to my PC rather than
> shown on screen. I expected it to show up on screen to be viewed (if it is a
> text file).
> 
> This is what I would like to be able to do as well as diffing revisions of a
> file etc.
> 
> Questions:
> 1) Does WebSVN need to be installed as part of the SVN installation on Linux 
> or
> is it just a different way to navigate the repository such that it could in 
> fact
> run on a *different* computer than the SVN server?

WebSVN requires the official Subversion client to be installed.

> 2) Is WebSVN strictly a read-only tool, i.e. it does not try to write anything
> into the repository?

Correct. Read-only/view.

For other WebSVN issues, please raise withe GitHub project, I will respond.

Michael

Re: GUI interface to Subversion via web browser?

[Nico Kadel-Garcia]

On Fri, May 24, 2024 at 10:03 AM Johan Corveleyn  wrote:
>
> On Fri, May 24, 2024 at 3:18 PM Mark Phippard  wrote:
> > On Fri, May 24, 2024 at 9:11 AM Johan Corveleyn  wrote:
>
> > > What lots of people these days are looking for (myself included) is a
> > > modern "Code Forge" ...
> >
> > Beanstalk has always seemed like a solid service:  https://beanstalkapp.com/
> > And Assembla still exists: https://get.assembla.com/
> >
> >
> > > Seriously, if we'd ever start such a sub-project under the Apache
> > > Subversion umbrella one day, I'd be interested in joining the effort
> > > :-).
> >
> > The Apache project for this is Allura: https://allura.apache.org/
>
> Thanks for these suggestions Mark. Interesting to look around a bit.
>
> Concerning Allura: I find it quite strange that this project is
> completely disconnected from the Subversion project, being both Apache
> projects. We don't know each other at all. This is the first time the
> name "Allura" is mentioned on users@s.a.o ever since I was subscribed
> (since 2010). On dev@s.a.o it was mentioned only once in 2013, during
> a discussion on where to move the issue tracker. Sounds like marketing
> / making contact with potentially interested communities was not high
> on the agenda.

"Apache related" lost its technology links when httpd was forked from
the original apache code, and  Apache became an organization and a
software license, not a supported software package.

Re: SVN issue - Repository - not able to login

[Roshan Pardeshi]

Hello Daniel,

We have checked from below link but not find the solution. If we create a
new repository named as *Utilities *that repository is getting created but
when user is trying to login that repository by using URL as -
*svn://192.168.213.190/SVN/Utilities
* authorization window is not coming
which ask for username and password.

https://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn
.serverconfig.svnserve.auth.general


Regards,


 



Roshan Pardeshi
Senior Executive
National Commodity & Derivatives Exchange Limited
<#SignatureSanitizer_SafeHtmlFilter_>
9167426129 <#SignatureSanitizer_SafeHtmlFilter_> /  022 - 6640 3225
<#SignatureSanitizer_SafeHtmlFilter_>
roshan.parde...@ncdex.com
/
as...@ncdex.com

Toll-free number 1800 266 2339 / 1800 103 4861
<#SignatureSanitizer_SafeHtmlFilter_>



On Mon, May 27, 2024 at 7:02 PM Daniel Sahlberg 
wrote:

> Den mån 27 maj 2024 kl 14:50 skrev Roshan Pardeshi <
> roshan.parde...@ncdex.com>:
>
>> Hello Daniel,
>>
>> We are using below mentioned path for access in SVN through
>> TortoiseSVN->Repo Browser.
>>
>> svn://___.__.__.___(server ip)/SVN/aedge
>>
>
> So you are using svnserve.
>
> Can you double check your settings in the Subversion book:
> https://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.auth.general
>
> Can you copy relevant sections from the svnserve.conf file in the
> repository on the server? Can you double check that the file you are using
> for password-db actually exists and that it contains relevant data?
>
> Please try to include as much information as possible in your e-mail and
> the more you are able to check yourself on the basis of the documentation
> and available resources the easier it will be to help you.
>
> Kind regards,
> Daniel Sahlberg
>
>
> 
>
>
>>
>> Regards,
>>
>>
>>  
>> 
>> 
>>
>> Roshan Pardeshi
>> Senior Executive
>> National Commodity & Derivatives Exchange Limited
>>
>> <#m_-1745979131062404214_m_333834782278983509_m_2296490561864706534_SignatureSanitizer_SafeHtmlFilter_>
>> 9167426129
>> <#m_-1745979131062404214_m_333834782278983509_m_2296490561864706534_SignatureSanitizer_SafeHtmlFilter_>
>>  /  022 - 6640 3225
>> <#m_-1745979131062404214_m_333834782278983509_m_2296490561864706534_SignatureSanitizer_SafeHtmlFilter_>
>> roshan.parde...@ncdex.com
>> 
>> /as...@ncdex.com
>> 
>> Toll-free number 1800 266 2339 / 1800 103 4861
>> <#m_-1745979131062404214_m_333834782278983509_m_2296490561864706534_SignatureSanitizer_SafeHtmlFilter_>
>>
>>
>>
>> On Thu, May 23, 2024 at 9:42 PM Daniel Sahlberg <
>> daniel.l.sahlb...@gmail.com> wrote:
>>
>>> Den tors 23 maj 2024 kl 18:03 skrev Roshan Pardeshi <
>>> roshan.parde...@ncdex.com>:
>>>
 Hello Team,

 Please find the my input inline below.

 Which protocol are you using to access the repository? - Tortoise SVN -
 Repo Browser

>>>
>>> Are you using Apache/mod_dav_svn (http[s]://..), svnserve
>>> (svn://.) or ssh+svnserve (svn+ssh://.)? (Or even file://..., but
>>> in that case you will not get an authentication prompt).
>>>
>>>
 Do you have other repositories where this works? - No

 Can you share your server configuration? - its a Redhat Linux with 16
 GB RAM and 4 core CPU.

>>>
>>> I mean the Apache httpd configuration if you use mod_dav_svn or the
>>> svnserve configuration if you use svnserve.
>>>
>>> The Subversion book has some great examples of how to setup
>>> authentication:
>>>
>>> https://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.auth.general
>>>
>>> https://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authn
>>>
>>> Kind regards,
>>> Daniel
>>>
>>>
>> Experience *'tick-by-tick*' broadcast on NCDEX's NextGen trading
>> platform. *www.ncdex.com *
>>
>> *Tweet: @ncdex, Facebook: TrustNCDEX, Youtube: NCDEX Ltd.*
>>
>> *Disclaimer:*
>>
>> *This email and any and all attachment/s hereto are intended solely for
>> the addressee/s, are strictly confidential and may be privileged. If you
>> are not the intended recipient, any reading, dissemination, copying or any
>> other use of this e-mail and the attachment/s is prohibited. If you have
>> received this email in error, 

Re: SVN issue - Repository - not able to login

[Daniel Sahlberg]

Den mån 27 maj 2024 kl 14:50 skrev Roshan Pardeshi <
roshan.parde...@ncdex.com>:

> Hello Daniel,
>
> We are using below mentioned path for access in SVN through
> TortoiseSVN->Repo Browser.
>
> svn://___.__.__.___(server ip)/SVN/aedge
>

So you are using svnserve.

Can you double check your settings in the Subversion book:
https://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.auth.general

Can you copy relevant sections from the svnserve.conf file in the
repository on the server? Can you double check that the file you are using
for password-db actually exists and that it contains relevant data?

Please try to include as much information as possible in your e-mail and
the more you are able to check yourself on the basis of the documentation
and available resources the easier it will be to help you.

Kind regards,
Daniel Sahlberg




>
> Regards,
>
>
>  
> 
> 
>
> Roshan Pardeshi
> Senior Executive
> National Commodity & Derivatives Exchange Limited
>
> <#m_333834782278983509_m_2296490561864706534_SignatureSanitizer_SafeHtmlFilter_>
> 9167426129
> <#m_333834782278983509_m_2296490561864706534_SignatureSanitizer_SafeHtmlFilter_>
>  /  022 - 6640 3225
> <#m_333834782278983509_m_2296490561864706534_SignatureSanitizer_SafeHtmlFilter_>
> roshan.parde...@ncdex.com
> /
> as...@ncdex.com
> 
> Toll-free number 1800 266 2339 / 1800 103 4861
> <#m_333834782278983509_m_2296490561864706534_SignatureSanitizer_SafeHtmlFilter_>
>
>
>
> On Thu, May 23, 2024 at 9:42 PM Daniel Sahlberg <
> daniel.l.sahlb...@gmail.com> wrote:
>
>> Den tors 23 maj 2024 kl 18:03 skrev Roshan Pardeshi <
>> roshan.parde...@ncdex.com>:
>>
>>> Hello Team,
>>>
>>> Please find the my input inline below.
>>>
>>> Which protocol are you using to access the repository? - Tortoise SVN -
>>> Repo Browser
>>>
>>
>> Are you using Apache/mod_dav_svn (http[s]://..), svnserve
>> (svn://.) or ssh+svnserve (svn+ssh://.)? (Or even file://..., but
>> in that case you will not get an authentication prompt).
>>
>>
>>> Do you have other repositories where this works? - No
>>>
>>> Can you share your server configuration? - its a Redhat Linux with 16 GB
>>> RAM and 4 core CPU.
>>>
>>
>> I mean the Apache httpd configuration if you use mod_dav_svn or the
>> svnserve configuration if you use svnserve.
>>
>> The Subversion book has some great examples of how to setup
>> authentication:
>>
>> https://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.auth.general
>>
>> https://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authn
>>
>> Kind regards,
>> Daniel
>>
>>
> Experience *'tick-by-tick*' broadcast on NCDEX's NextGen trading
> platform. *www.ncdex.com *
>
> *Tweet: @ncdex, Facebook: TrustNCDEX, Youtube: NCDEX Ltd.*
>
> *Disclaimer:*
>
> *This email and any and all attachment/s hereto are intended solely for
> the addressee/s, are strictly confidential and may be privileged. If you
> are not the intended recipient, any reading, dissemination, copying or any
> other use of this e-mail and the attachment/s is prohibited. If you have
> received this email in error, please notify the sender immediately by email
> and also permanently delete the email. Copyright reserved.*
>
> *All communications, incoming and outgoing, may be recorded and are
> monitored for legitimate business purposes. NCDEX is not responsible for
> any damage caused by virus or alteration of the e-mail or the accompanying
> attachment/s by a third party or otherwise. NCDEX disclaims all liability
> for any loss or damage whatsoever arising out of or resulting from the
> receipt, use, transmission or interruption of this email. Any views or
> opinions expressed in this email are those of the author only.*
>

Re: SVN issue - Repository - not able to login

[Roshan Pardeshi]

Hello Daniel,

We are using below mentioned path for access in SVN through
TortoiseSVN->Repo Browser.

svn://___.__.__.___(server ip)/SVN/aedge

Regards,


 



Roshan Pardeshi
Senior Executive
National Commodity & Derivatives Exchange Limited
<#SignatureSanitizer_SafeHtmlFilter_>
9167426129 <#SignatureSanitizer_SafeHtmlFilter_> /  022 - 6640 3225
<#SignatureSanitizer_SafeHtmlFilter_>
roshan.parde...@ncdex.com
/
as...@ncdex.com

Toll-free number 1800 266 2339 / 1800 103 4861
<#SignatureSanitizer_SafeHtmlFilter_>



On Thu, May 23, 2024 at 9:42 PM Daniel Sahlberg 
wrote:

> Den tors 23 maj 2024 kl 18:03 skrev Roshan Pardeshi <
> roshan.parde...@ncdex.com>:
>
>> Hello Team,
>>
>> Please find the my input inline below.
>>
>> Which protocol are you using to access the repository? - Tortoise SVN -
>> Repo Browser
>>
>
> Are you using Apache/mod_dav_svn (http[s]://..), svnserve
> (svn://.) or ssh+svnserve (svn+ssh://.)? (Or even file://..., but
> in that case you will not get an authentication prompt).
>
>
>> Do you have other repositories where this works? - No
>>
>> Can you share your server configuration? - its a Redhat Linux with 16 GB
>> RAM and 4 core CPU.
>>
>
> I mean the Apache httpd configuration if you use mod_dav_svn or the
> svnserve configuration if you use svnserve.
>
> The Subversion book has some great examples of how to setup authentication:
>
> https://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.auth.general
>
> https://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authn
>
> Kind regards,
> Daniel
>
>

-- 


Experience *'tick-by-tick*' broadcast on NCDEX's NextGen trading 
platform. **www.ncdex.com **

*Tweet: @ncdex, 
Facebook: TrustNCDEX, Youtube: NCDEX Ltd.*
**

*Disclaimer:*

*This email 
and any and all attachment/s hereto are intended solely for the 
addressee/s, are strictly confidential and may be privileged. If you are 
not the intended recipient, any reading, dissemination, copying or any 
other use of this e-mail and the attachment/s is prohibited. If you have 
received this email in error, please notify the sender immediately by email 
and also permanently delete the email. Copyright reserved.*

*All 
communications, incoming and outgoing, may be recorded and are monitored 
for legitimate business purposes. NCDEX is not responsible for any damage 
caused by virus or alteration of the e-mail or the accompanying 
attachment/s by a third party or otherwise. NCDEX disclaims all liability 
for any loss or damage whatsoever arising out of or resulting from the 
receipt, use, transmission or interruption of this email. Any views or 
opinions expressed in this email are those of the author only.*

Re: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Johan Corveleyn]

On Sat, May 25, 2024 at 12:12 AM Williams, James P. {Jim}
(JSC-CD4)[KBR Wyle Services, LLC] via users
 wrote:
>
> > Den lör 11 maj 2024 kl 03:00 skrev Williams, James P. {Jim} (JSC-CD4)[KBR 
> > Wyle Services, LLC] via users :
>
> > You previously mentioned Subversion 1.14.1, is that on the server or on the 
> > client?
>
> I'm using 1.14.1 on both the client and server.
>
> > Still it would be interesting to compare just to rule out a problem within 
> > the repository. You can use svnserve directly or tunneled over SSH, see the 
> > Subversion book:
>
> With svnserve 1.14.1, I see no problems.  Checkouts complete every time.  I'm 
> not sure what to conclude about that.  It's a different protocol, so it 
> doesn't necessarily exonerate the client or the network.
>
> > >   #0  epoll_wait   /usr/lib64/libc.so.6
>
> > Waiting for a reply from the server ... ?
>
> Yeah, that'd be my guess.  When the hang occurs, I've got about 90% of the 
> working copy checked out.  I expect the client is waiting for more bytes to 
> arrive on the socket.
>
> > Do you see any activity on the server (CPU / disk) during this time?
>
> The server is well-behaved throughout all of my tests.  It shows no CPU spike 
> or log messages hinting that it's noticed a problem.

That's why my bet is still on "something between client and server"
(proxy, reverse-proxy, security scanning soft, ...) that messes with
the network transfer (http or https). That would explain the symptoms
you're seeing (client hangs waiting for network (and sometimes
crashes), server has nothing to do and doesn't report anything
special).

-- 
Johan

Re: GUI interface to Subversion via web browser?

[Ryan Carsten Schmidt]

On May 26, 2024, at 14:58, Bo Berglund wrote:

> My problem with ApacheSVN interface:
> 
> With the Apache SVN installation where I keep the backups (using svnsync) it 
> is
> not possible to display the top level so the project types can be shown and
> stepped into.
> 
> I just get a "Forbidden" error if I try to use the URL that should get me to 
> the
> top.

Use "SVNListParentPath On"

https://svnbook.red-bean.com/en/1.6/svn.ref.mod_dav_svn.conf.html

Re: GUI interface to Subversion via web browser?

[Bo Berglund]

On Sun, 26 May 2024 10:24:27 -, Michael Osipov  wrote:

>> WebSVN is still actively maintained (version 2.8.4 was released 2 months 
>> ago) and offers the features you're looking for (view files, logs and 
>> diffs) and more.
>> 
>> I'm not aware of any screenshots, but installing it for evaluation 
>> purposes is reasonably straightforward.
>
>More or less solve maintainer of WebSVN here. I try to keep it alive with 
>fixes and small improvements for the entire community. Thought, I cannot 
>compare it to ViewVC, never used.
>
>> For small to medium-scale projects, I find it a really helpful addition 
>> to the Subversion server. For large-scale projects with more than a 
>> thousand branches or tags, performance will become an issue.
>
>Yes, that is a long standing problem [1] I'd like to solve, but cannot ATM due 
>to lack of time and knowledge in that area.
>
>Michael

Thanks for the explanation!

Our repository contains a fair number of projects organized as:
"project type"/"project name"/trunk,branches,tags

The "project type" level consists of 11 named type directories.
Below each type are the actual project directories with the project name as the
dir name.
And within each project we start with trunk-tags-branches dirs until we get to
the actual data.

There ia usually just 1 or 2 persons working on each project.

And the number of commits are rather limited as well as the tags and branches.
The latter are mostly non-existing or just a handful.

My problem with ApacheSVN interface:

With the Apache SVN installation where I keep the backups (using svnsync) it is
not possible to display the top level so the project types can be shown and
stepped into.

I just get a "Forbidden" error if I try to use the URL that should get me to the
top.

If I know the top level name I can get to a navigable list and drill down from
there.

So all other levels I can navigate with the web browser, but there is not much
one can do there, for instance viewing the log message tree for a file etc.

And if I click a file in the list it will be downloaded to my PC rather than
shown on screen. I expected it to show up on screen to be viewed (if it is a
text file).

This is what I would like to be able to do as well as diffing revisions of a
file etc.

Questions:
1) Does WebSVN need to be installed as part of the SVN installation on Linux or
is it just a different way to navigate the repository such that it could in fact
run on a *different* computer than the SVN server?

2) Is WebSVN strictly a read-only tool, i.e. it does not try to write anything
into the repository?

TIA


-- 
Bo Berglund
Developer in Sweden

Re: GUI interface to Subversion via web browser?

[Michael Osipov]

On 2024/05/22 08:23:54 Philippe Andersson wrote:
> On 22/05/2024 10:06, Bo Berglund wrote:
> > ... I hope this is not totally OT ...
> > 
> > I am running an SVN server on an Ubuntu 20.04 LTS system and I have the 
> > Apache
> > connection so I can access it via its web interface.
> > 
> > This works but is *very limited* in functionality, so I am looking for some 
> > kind
> > of GUI interface that can be added to my Ubuntu SVN installation and gives 
> > me
> > functionality to view file revisions, logs etc and also diff revisions 
> > using the
> > web view.
> > 
> > Many years ago (like 20+ years) when I worked at a company using CVS there 
> > was a
> > web interface which had very useful functions in this regard. It was all 
> > running
> > on Windows Server.
> > 
> > It was named ViewCVS (Python based) and was accessed using a web browser 
> > towards
> > the CVS server.
> > 
> > I have tried to search for something similar for SVN and found WebSVN on 
> > Github:
> > https://github.com/websvnphp/websvn
> > 
> > and:
> > 
> > https://websvnphp.github.io/
> > 
> > However, I have yet to find any examples on how its displays look or work 
> > and it
> > also seems to be a rather old project...
> WebSVN is still actively maintained (version 2.8.4 was released 2 months 
> ago) and offers the features you're looking for (view files, logs and 
> diffs) and more.
> 
> I'm not aware of any screenshots, but installing it for evaluation 
> purposes is reasonably straightforward.

More or less solve maintainer of WebSVN here. I try to keep it alive with fixes 
and small improvements for the entire community. Thought, I cannot compare it 
to ViewVC, never used.

> For small to medium-scale projects, I find it a really helpful addition 
> to the Subversion server. For large-scale projects with more than a 
> thousand branches or tags, performance will become an issue.

Yes, that is a long standing problem [1] I'd like to solve, but cannot ATM due 
to lack of time and knowledge in that area.

Michael

[1] https://github.com/websvnphp/websvn/issues/78

RE: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users]

> Den lör 11 maj 2024 kl 03:00 skrev Williams, James P. {Jim} (JSC-CD4)[KBR 
> Wyle Services, LLC] via users :
> You previously mentioned Subversion 1.14.1, is that on the server or on the 
> client?

I'm using 1.14.1 on both the client and server.

> Still it would be interesting to compare just to rule out a problem within 
> the repository. You can use svnserve directly or tunneled over SSH, see the 
> Subversion book:

With svnserve 1.14.1, I see no problems.  Checkouts complete every time.  I'm 
not sure what to conclude about that.  It's a different protocol, so it doesn't 
necessarily exonerate the client or the network.

> >   #0  epoll_wait   /usr/lib64/libc.so.6
> Waiting for a reply from the server ... ?

Yeah, that'd be my guess.  When the hang occurs, I've got about 90% of the 
working copy checked out.  I expect the client is waiting for more bytes to 
arrive on the socket.

> Do you see any activity on the server (CPU / disk) during this time?

The server is well-behaved throughout all of my tests.  It shows no CPU spike 
or log messages hinting that it's noticed a problem.

> Memory allocation?

Yeah, both forms of core dumps I've seen have memory/pool allocation at the top 
of the stack.  Maybe some odd reentrancy case is being tickled that's not often 
seen.  It points at a likely secondary problem, a bug in the client.

> Parsing the XML message from the server?
> Can you catch/view the actual XML message sent from the server? I'm thinking 
> if this is mangled in some strange way that is upsetting the XML parser.

We're not able to install tools like wireshark, if that's what you're 
suggesting.  I don't see a way to get to that XML other than doctoring SVN 
source.

> Again something with memory allocation - same here, can you see what the 
> server is actually sending?

Same answer.

> I don't immediately see the call stacks above and the fact that it would fail 
> more often if the WC is on an NFS drive. Possibly if the NFS drive is slower 
> and this causes some kind of timeout? Can you create a ramdisk and have the 
> WC there temporary and see if there is a difference?

I think NFS definitely slows things down, and that change in timing makes the 
hangs and crashes more likely.  Unfortunately, I don't have the access needed 
to create a ramdisk.  I'm able to checkout onto a local or NFS-mounted disk 
though.  I would think the former is equivalent.  No?

Thanks for the reply, Daniel.

Jim

From: Daniel Sahlberg 
Sent: Saturday, May 11, 2024 1:51 PM
To: Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] 

Cc: users@subversion.apache.org
Subject: Re: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

CAUTION: This email originated from outside of NASA.  Please take care when 
clicking links or opening attachments.  Use the "Report Message" button to 
report suspicious messages to the NASA SOC.


Hi,

I've added a few comments/questions below.

Kind regards,
Daniel Sahlberg

Den lör 11 maj 2024 kl 03:00 skrev Williams, James P. {Jim} (JSC-CD4)[KBR Wyle 
Services, LLC] via users 
mailto:users@subversion.apache.org>>:
> How did you upgrade your server from RHEL 6 to RHEL 8?

Because so much changed from RHEL 6 to 8, including Apache from 2.2.15 to 
2.4.37, all the Apache modules, etc., I started from the skeleton configuration 
the operating system provides and made mostly the same customizations we had 
for RHEL 6, or modernized them where the docs said things changed.  Mostly, 
that was tweaks to authentication (from LDAP to Kerberos), SSL, and the SVN 
endpoints.  Browser access to all SVN and ViewVC pages seems to work fine.

You previously mentioned Subversion 1.14.1, is that on the server or on the 
client?

[...]

> And do the problems happen if you use svn:// rather than https:// ?

I thought svn:// worked only with svnserve, which we don't run.  Are you 
suggesting I try to run it as a test, or that I consider abandoning Apache in 
favor of it?  Yikes; that'd be painful.

I hear you on the HTTP integration.  We have about 2000 repos and a few hundred 
developers.  I've supported that server for at least 15 years, and it hasn't 
been too bad...until now.

I have personally only ever used Subversion over http/https (except for testing 
purposes) and I haven't had any of the problems described by Nico - I guess 
YMMV...

Still it would be interesting to compare just to rule out a problem within the 
repository. You can use svnserve directly or tunneled over SSH, see the 
Subversion book:

https://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshauth


On Fri, May 10, 2024 at 4:17 PM Williams, James P. {Jim} (JSC-CD4)[KBR
Wyle Services, LLC] via users 
mailto:users@subversion.apache.org>> wrote:
>

Re: GUI interface to Subversion via web browser?

[Nathan Hartman]

On Fri, May 24, 2024 at 10:03 AM Johan Corveleyn  wrote:
>
> On Fri, May 24, 2024 at 3:18 PM Mark Phippard  wrote:
> > On Fri, May 24, 2024 at 9:11 AM Johan Corveleyn  wrote:
>
> > > What lots of people these days are looking for (myself included) is a
> > > modern "Code Forge" ...
> >
> > Beanstalk has always seemed like a solid service:  https://beanstalkapp.com/
> > And Assembla still exists: https://get.assembla.com/
> >
> >
> > > Seriously, if we'd ever start such a sub-project under the Apache
> > > Subversion umbrella one day, I'd be interested in joining the effort
> > > :-).
> >
> > The Apache project for this is Allura: https://allura.apache.org/
>
> Thanks for these suggestions Mark. Interesting to look around a bit.
>
> Concerning Allura: I find it quite strange that this project is
> completely disconnected from the Subversion project, being both Apache
> projects. We don't know each other at all. This is the first time the
> name "Allura" is mentioned on users@s.a.o ever since I was subscribed
> (since 2010). On dev@s.a.o it was mentioned only once in 2013, during
> a discussion on where to move the issue tracker. Sounds like marketing
> / making contact with potentially interested communities was not high
> on the agenda.
>
> --
> Johan


Well now, this is interesting. Just a quick glance into the Allura
site and at [1] under "Code Repository" it says Allura supports Git,
Mercurial, and Subversion. The feature comparison page at [2] may be
interesting, as it helps discover some other similar and open source
products.

I sent a "hello" message to Allura's dev list :-) [3]

[1] https://forge-allura.apache.org/p/allura/wiki/Features/

[2] https://forge-allura.apache.org/p/allura/wiki/Feature%20Comparison/

[3] https://lists.apache.org/thread/gns66ls2v3hqzkxmgwl5ykpqkd4dxpn1

Cheers,
Nathan

Re: GUI interface to Subversion via web browser?

[Sean McBride]

On 24 May 2024, at 9:10, Johan Corveleyn wrote:

> What lots of people these days are looking for (myself included) is a
>
> modern "Code Forge" [1][2][3], like GitHub/Lab/... or like the Forgejo
>
> project [4] with its cloud-hosted platform Codeberg [5], but then for
>
> Subversion.

I've never tried, but I once considered this:

https://rhodecode.com/

which supports svn.

Sean

Re: GUI interface to Subversion via web browser?

[Jeffrey Walton]

On Fri, May 24, 2024 at 9:10 AM Johan Corveleyn  wrote:
>
> On Wed, May 22, 2024 at 10:06 AM Bo Berglund  wrote:
> > I am running an SVN server on an Ubuntu 20.04 LTS system and I have the 
> > Apache
> > connection so I can access it via its web interface.
> >
> > This works but is *very limited* in functionality, so I am looking for some 
> > kind
> > of GUI interface that can be added to my Ubuntu SVN installation and gives 
> > me
> > functionality to view file revisions, logs etc and also diff revisions 
> > using the
> > web view.
>
> What lots of people these days are looking for (myself included) is a
> modern "Code Forge" [1][2][3], like GitHub/Lab/... or like the Forgejo
> project [4] with its cloud-hosted platform Codeberg [5], but then for
> Subversion.

++. Mee too.

I've had enough of Git, its anti-patterns, and its unusability. I'm
ready to go back to the good old days of Mercurial and Subversion. I
long for the simplistic days of "it just works."

> I'd like a modern web interface (hostable on-premise or in the cloud)
> that includes:
> - Version control repositories (and management thereof)
> - Online viewing, searching, diffing, ... (like ViewVC)
> - Online editing, committing directly from the web interface
> - Ability to manage patches aka pull requests
> - Mailing lists and Forums
> - Notification system (with ability to individually configure "watch" 
> patterns)
> - Issue tracker
> - Code reviews
> - Wiki
> - General (plugable) "Actions" framework
> - CI system with buildagents / bots
> - Artifact repository
> - Enterprise level user management
> - ...
> - Also accessible from mobile devices of course
>
> Oh, and if possible it should flexibly integrate with external systems
> that may already be present in your environment, like if you have a
> JIRA issue tracker or wiki or ... you would want to integrate that one
> instead of the "default / reference" implementation.
>
> I'm dreaming of course, but wouldn't that be nice?
>
> Seriously, if we'd ever start such a sub-project under the Apache
> Subversion umbrella one day, I'd be interested in joining the effort
> :-).
>
> [1] https://www.wikidata.org/wiki/Wikidata:WikiProject_Informatics/Forges
> [2] https://en.wikipedia.org/wiki/Forge_(software)
> [3] https://en.wikipedia.org/wiki/Comparison_of_source-code-hosting_facilities
> [4] https://forgejo.org/
> [5] https://codeberg.org/

Re: GUI interface to Subversion via web browser?

[Johan Corveleyn]

On Fri, May 24, 2024 at 3:18 PM Mark Phippard  wrote:
> On Fri, May 24, 2024 at 9:11 AM Johan Corveleyn  wrote:

> > What lots of people these days are looking for (myself included) is a
> > modern "Code Forge" ...
>
> Beanstalk has always seemed like a solid service:  https://beanstalkapp.com/
> And Assembla still exists: https://get.assembla.com/
>
>
> > Seriously, if we'd ever start such a sub-project under the Apache
> > Subversion umbrella one day, I'd be interested in joining the effort
> > :-).
>
> The Apache project for this is Allura: https://allura.apache.org/

Thanks for these suggestions Mark. Interesting to look around a bit.

Concerning Allura: I find it quite strange that this project is
completely disconnected from the Subversion project, being both Apache
projects. We don't know each other at all. This is the first time the
name "Allura" is mentioned on users@s.a.o ever since I was subscribed
(since 2010). On dev@s.a.o it was mentioned only once in 2013, during
a discussion on where to move the issue tracker. Sounds like marketing
/ making contact with potentially interested communities was not high
on the agenda.

-- 
Johan

Re: GUI interface to Subversion via web browser?

[Mark Phippard]

On Fri, May 24, 2024 at 9:11 AM Johan Corveleyn  wrote:
>
> On Wed, May 22, 2024 at 10:06 AM Bo Berglund  wrote:
> > I am running an SVN server on an Ubuntu 20.04 LTS system and I have the 
> > Apache
> > connection so I can access it via its web interface.
> >
> > This works but is *very limited* in functionality, so I am looking for some 
> > kind
> > of GUI interface that can be added to my Ubuntu SVN installation and gives 
> > me
> > functionality to view file revisions, logs etc and also diff revisions 
> > using the
> > web view.
>
> What lots of people these days are looking for (myself included) is a
> modern "Code Forge" [1][2][3], like GitHub/Lab/... or like the Forgejo
> project [4] with its cloud-hosted platform Codeberg [5], but then for
> Subversion.
>
> I'd like a modern web interface (hostable on-premise or in the cloud)
> that includes:
> - Version control repositories (and management thereof)
> - Online viewing, searching, diffing, ... (like ViewVC)
> - Online editing, committing directly from the web interface
> - Ability to manage patches aka pull requests
> - Mailing lists and Forums
> - Notification system (with ability to individually configure "watch" 
> patterns)
> - Issue tracker
> - Code reviews
> - Wiki
> - General (plugable) "Actions" framework
> - CI system with buildagents / bots
> - Artifact repository
> - Enterprise level user management
> - ...
> - Also accessible from mobile devices of course
>
> Oh, and if possible it should flexibly integrate with external systems
> that may already be present in your environment, like if you have a
> JIRA issue tracker or wiki or ... you would want to integrate that one
> instead of the "default / reference" implementation.
>
> I'm dreaming of course, but wouldn't that be nice?

Beanstalk has always seemed like a solid service:  https://beanstalkapp.com/
And Assembla still exists: https://get.assembla.com/


> Seriously, if we'd ever start such a sub-project under the Apache
> Subversion umbrella one day, I'd be interested in joining the effort
> :-).

The Apache project for this is Allura: https://allura.apache.org/

Mark

Re: GUI interface to Subversion via web browser?

[Johan Corveleyn]

On Wed, May 22, 2024 at 10:06 AM Bo Berglund  wrote:
> I am running an SVN server on an Ubuntu 20.04 LTS system and I have the Apache
> connection so I can access it via its web interface.
>
> This works but is *very limited* in functionality, so I am looking for some 
> kind
> of GUI interface that can be added to my Ubuntu SVN installation and gives me
> functionality to view file revisions, logs etc and also diff revisions using 
> the
> web view.

What lots of people these days are looking for (myself included) is a
modern "Code Forge" [1][2][3], like GitHub/Lab/... or like the Forgejo
project [4] with its cloud-hosted platform Codeberg [5], but then for
Subversion.

I'd like a modern web interface (hostable on-premise or in the cloud)
that includes:
- Version control repositories (and management thereof)
- Online viewing, searching, diffing, ... (like ViewVC)
- Online editing, committing directly from the web interface
- Ability to manage patches aka pull requests
- Mailing lists and Forums
- Notification system (with ability to individually configure "watch" patterns)
- Issue tracker
- Code reviews
- Wiki
- General (plugable) "Actions" framework
- CI system with buildagents / bots
- Artifact repository
- Enterprise level user management
- ...
- Also accessible from mobile devices of course

Oh, and if possible it should flexibly integrate with external systems
that may already be present in your environment, like if you have a
JIRA issue tracker or wiki or ... you would want to integrate that one
instead of the "default / reference" implementation.

I'm dreaming of course, but wouldn't that be nice?

Seriously, if we'd ever start such a sub-project under the Apache
Subversion umbrella one day, I'd be interested in joining the effort
:-).

[1] https://www.wikidata.org/wiki/Wikidata:WikiProject_Informatics/Forges
[2] https://en.wikipedia.org/wiki/Forge_(software)
[3] https://en.wikipedia.org/wiki/Comparison_of_source-code-hosting_facilities
[4] https://forgejo.org/
[5] https://codeberg.org/

-- 
Johan

Re: GUI interface to Subversion via web browser?

[Yasuhito FUTATSUKI]

On 2024/05/24 1:56, Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] 
via users wrote:
>>> ViewVC 1.2.3 does not support Python 3.
>>
>> The fact that their newest release, 1.2.3, still requires python 2 does
>> not exactly fill me with confidence with respect to the health of the
>> project. :(
> 
> For what it's worth, I've been using the latest ViewVC commits along master 
> for about a year and have seen no problems.  That's been with Python 3.8 and 
> 3.11 so far.  I had to ensure some environment variables were exported to CGI 
> scripts so ViewVC can find SVN's Python bindings, something like this in the 
> server start script,
> 
>export PYTHONPATH=path-to-svn-python-bindings:$PYTHONPATH
>export LD_LIBRARY_PATH=path-to-svn-libs:$LD_LIBRARY_PATH
> 
> and this in the server configuration files,
> 
>PassEnv PYTHONPATH LD_LIBRARY_PATH
> 
> As simple as that looks, I had to add debugging to ViewVC to figure out why 
> the CGI script was having problems, but that has nothing to do with using 
> master commits.

The only release blocker of ViewVC 1.3.0 is the cvsdb support.

https://github.com/viewvc/viewvc/issues/250#issuecomment-1332383135
https://github.com/viewvc/viewvc/issues/250#issuecomment-1332515609
https://github.com/viewvc/viewvc/issues/213

However there is no progress for the issue over a year, because
there is no one interested in it *and* having much time *and* having
ability to write the code for it. So both the worry for the health
of the project and stability of the code of master branch seems
to be correct for me.

Cheers,
-- 
Yasuhito FUTATSUKI 

RE: [EXTERNAL] [BULK] Re: GUI interface to Subversion via web browser?

[Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users]

> > ViewVC 1.2.3 does not support Python 3.
> 
> The fact that their newest release, 1.2.3, still requires python 2 does
> not exactly fill me with confidence with respect to the health of the
> project. :(

For what it's worth, I've been using the latest ViewVC commits along master for 
about a year and have seen no problems.  That's been with Python 3.8 and 3.11 
so far.  I had to ensure some environment variables were exported to CGI 
scripts so ViewVC can find SVN's Python bindings, something like this in the 
server start script,

   export PYTHONPATH=path-to-svn-python-bindings:$PYTHONPATH
   export LD_LIBRARY_PATH=path-to-svn-libs:$LD_LIBRARY_PATH

and this in the server configuration files,

   PassEnv PYTHONPATH LD_LIBRARY_PATH

As simple as that looks, I had to add debugging to ViewVC to figure out why the 
CGI script was having problems, but that has nothing to do with using master 
commits.

Good luck.

Jim

Re: GUI interface to Subversion via web browser?

[Sean McBride]

On 22 May 2024, at 17:52, Yasuhito FUTATSUKI wrote:

> ViewVC 1.2.3 does not support Python 3.

The fact that their newest release, 1.2.3, still requires python 2 does not 
exactly fill me with confidence with respect to the health of the project. :(

Sean

Re: SVN issue - Repository - not able to login

[Daniel Sahlberg]

Den tors 23 maj 2024 kl 18:03 skrev Roshan Pardeshi <
roshan.parde...@ncdex.com>:

> Hello Team,
>
> Please find the my input inline below.
>
> Which protocol are you using to access the repository? - Tortoise SVN -
> Repo Browser
>

Are you using Apache/mod_dav_svn (http[s]://..), svnserve (svn://.)
or ssh+svnserve (svn+ssh://.)? (Or even file://..., but in that case
you will not get an authentication prompt).


> Do you have other repositories where this works? - No
>
> Can you share your server configuration? - its a Redhat Linux with 16 GB
> RAM and 4 core CPU.
>

I mean the Apache httpd configuration if you use mod_dav_svn or the
svnserve configuration if you use svnserve.

The Subversion book has some great examples of how to setup authentication:
https://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.auth.general
https://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authn

Kind regards,
Daniel

Re: SVN issue - Repository - not able to login

[Roshan Pardeshi]

Hello Team,

Please find the my input inline below.

Which protocol are you using to access the repository? - Tortoise SVN -
Repo Browser

Do you have other repositories where this works? - No

Can you share your server configuration? - its a Redhat Linux with 16 GB
RAM and 4 core CPU.

Regards,




 



Roshan Pardeshi
Senior Executive
National Commodity & Derivatives Exchange Limited
<#SignatureSanitizer_SafeHtmlFilter_>
9167426129 <#SignatureSanitizer_SafeHtmlFilter_> /  022 - 6640 3225
<#SignatureSanitizer_SafeHtmlFilter_>
roshan.parde...@ncdex.com
/
as...@ncdex.com

Toll-free number 1800 266 2339 / 1800 103 4861
<#SignatureSanitizer_SafeHtmlFilter_>



On Thu, May 23, 2024 at 7:41 PM Daniel Sahlberg 
wrote:

> Den tors 23 maj 2024 kl 16:07 skrev Roshan Pardeshi <
> roshan.parde...@ncdex.com>:
>
>> Hi All,
>>
>> We are not getting Authentication window(using TortoriseSVN Repo Browser)
>>  after creating a new repository in SVN to access that repository
>>
>> Else if we are getting authentication window then after input of username
>> and password of user its showing error message as "Authentication
>> failed"
>>
>> Requesting to please help on this issue.
>>
>> Below is the steps we are following to create repository
>>
>> Home path: /home/svnadmin
>> # cd /SVN
>> # svnadmin create YAALA (Repository Name: YAALA)
>>
>
> Which protocol are you using to access the repository?
>
> Do you have other repositories where this works?
>
> Can you share your server configuration?
>
> Kind regards,
> Daniel Sahlberg
>
>

-- 


Experience *'tick-by-tick*' broadcast on NCDEX's NextGen trading 
platform. **www.ncdex.com **

*Tweet: @ncdex, 
Facebook: TrustNCDEX, Youtube: NCDEX Ltd.*
**

*Disclaimer:*

*This email 
and any and all attachment/s hereto are intended solely for the 
addressee/s, are strictly confidential and may be privileged. If you are 
not the intended recipient, any reading, dissemination, copying or any 
other use of this e-mail and the attachment/s is prohibited. If you have 
received this email in error, please notify the sender immediately by email 
and also permanently delete the email. Copyright reserved.*

*All 
communications, incoming and outgoing, may be recorded and are monitored 
for legitimate business purposes. NCDEX is not responsible for any damage 
caused by virus or alteration of the e-mail or the accompanying 
attachment/s by a third party or otherwise. NCDEX disclaims all liability 
for any loss or damage whatsoever arising out of or resulting from the 
receipt, use, transmission or interruption of this email. Any views or 
opinions expressed in this email are those of the author only.*

Re: SVN issue - Repository - not able to login

[Daniel Sahlberg]

Den tors 23 maj 2024 kl 16:07 skrev Roshan Pardeshi <
roshan.parde...@ncdex.com>:

> Hi All,
>
> We are not getting Authentication window(using TortoriseSVN Repo Browser)
>  after creating a new repository in SVN to access that repository
>
> Else if we are getting authentication window then after input of username
> and password of user its showing error message as "Authentication
> failed"
>
> Requesting to please help on this issue.
>
> Below is the steps we are following to create repository
>
> Home path: /home/svnadmin
> # cd /SVN
> # svnadmin create YAALA (Repository Name: YAALA)
>

Which protocol are you using to access the repository?

Do you have other repositories where this works?

Can you share your server configuration?

Kind regards,
Daniel Sahlberg