Re: Can't connect to github anymore

[Olivier Sannier]

Le 13/01/2024 à 22꞉11, Nico Kadel-Garcia a écrit :

On Sat, Jan 13, 2024 at 4:02 PM Johan Corveleyn  wrote:

On Sat, Jan 13, 2024 at 8:28 PM roger21  wrote:

hey there

suddenly i can't connect to github anymore (svn update or svn checkout)

i get the following error:

svn checkouthttps://github.com/roger21/fract.git
svn: E170013: Unable to connect to a repository at URL
'https://github.com/roger21/fract.git'
svn: E160013: '/roger21/fract.git' path not found

Apparently, GitHub has removed its support for the Subversion protocol:

https://github.blog/changelog/2024-01-08-subversion-has-been-sunset/

--
Johan

The "git-svn" module has been my go-to tool for accessing legacy
Subversion repos for some time. There are not many compelling reasons
to use Subversion anymore, except the ability to check out only
subdirectories from a branch and the insistence that a single central
repository is the only source of truth.



Partial checkouts are somewhat possible with GIT but what is preventing 
me from migrating our repository is the lack of svn:external mechanism.
I don't want multirepos, and even then submodules are to be updated 
manually everytime where svn:external are automatically up to date.
And ideally, I would also need file externals support even if I could 
settle for folder external if that's all there is.
I looked a various solutions but none where as easy to use for 
developers than externals when doing a "svn update" at the root of the 
checkout.


That being said, I'd be quite happy to be proven wrong.

Re: win32svn for 1.9.1?

[Olivier Sannier]

On 08/09/2015 18:57, Win32Svn wrote:



On 2015-09-08 13:00, Stefan Hett wrote:

On 9/7/2015 10:21 PM, Win32Svn wrote:

On 2015-09-07 18:59, Barry Scott wrote:
On 7 Sep 2015, at 11:43, Andreas Stieger  
wrote:


Hi,

Barry Scott wrote:
I see that the recent 1.7 and 1.8 win32svn builds being 
announced, thanks for

them.

Do you know when the svn 1.9 win32svn build might be available?

Available at other binary "vendors":
https://subversion.apache.org/packages.html#windows
Sadly only win32svn packages the include files that are needed to 
write

code against svn. In my case I use win32svn as the basis of the pysvn
win32 build.

Barry



Hi Barry!

I'm sorry to say there won't be any 1.9.x build of Win32SVN.
You can read about it on http://alagazam.net   (click the 1.9.x info 
link on the right)


Regards,
David Darj  a.k.a. Alagazam
Maintainer of Win32SVN
http://alagazam.net

ps.
If you like my work, please support this project by donating at
http://sourceforge.net/donate/index.php?group_id=357628



Hi David,

I'm wondering which particular VS6 issue you are referring to in that 
note.
I've been told the only known issues atm not working using VS6 would 
be in the javahl code (due to the template code) which I assume is 
not the issue you are talking about, or is it?




Hi Stefan

I don't remember exactly now, but I gave one of the 1.9.0-alpha a shot 
with my build scripts (you can find them on sourceforge).
There were a lot more compilation errors than in 1.8.x where I've 
already patched a lot, and the time to look deeper then didn't exist.
Maybe there isn't any specific windows api issues or other features, 
but the old C standard (MS-standard) in VC6 makes the burden, right 
now at least, to much.


Regards,
David Darj  a.k.a. Alagazam
Maintainer of Win32SVN


Hello David,

Do you think it would be possible to migrate the scripts to VC2010?
I mean, I have it installed and am using it on a regular basis, so I 
could help with building part if need be.


Regards,
Olivier

svn list gives E160016 error on a specific URL

[Olivier Sannier]

Hello,

I'm trying to use SVN on Windows to connect to the SVN interface of a 
GitHub repository as it's much easier to integrate in my overall setup.
Using SVN 1.6.16 (CollabNet build), I was able to issue this command 
successfully:


svn list --non-interactive 
https://github.com/project-jedi/jcl/trunk/jcl@HEAD


where it gives me a nice list of what's inside that folder.

Considering that version 1.6 is quite outdated, I decided to upgrade my 
environment to version 1.8.11 (Alagazam.net build)
Unfortunately, when I issue the exact same command from the exact same 
computer, here is what I now get:


svn: E160016: Can't get entries of non-directory

That's very strange because jcl is a folder.
Using the TortoiseSVN build based on SVN 1.8.13, I also get the same 
error message when using the repository browser on that folder.


Now, if I issue that command:

svn list --non-interactive 
https://github.com/project-jedi/jcl/trunk/jcl/source@HEAD


then it works with both 1.6 and 1.8 versions, clearly indicating that 
jcl is indeed a folder.


What's wrong with that specific folder in that repository? And why is it 
only happening with the most recent versions of SVN?


Thanks a lot in advance for any answer.

Regards,

Olivier

Re: Managing modifications to an open source product

[Olivier Sannier]

 On 14/10/2010 21:45, Dan Nessett wrote:

On Thu, 14 Oct 2010 15:38:41 -0400, Bob Archer wrote:


I develop for a site that uses Mediawiki (MW). We make some
modifications to it before deployment. Generally, (using subversion) we
check out a tagged version into a workspace, recursively delete the
.svn directories, modify a small number of files, add some of our own
extensions, and then commit the result into our own repository. We then
work with the source from there.

This approach means we have to track MW bug-fixes and add them to our
modified version. I was wondering if there is a better way to
accomplish the same objective. For example, we can use the
svn:externals property to point to the MW repository version of the
extensions we use, so each time they are updated, all we need to do is
svn up on the externals directory.

The main source is a different story. Since we modify some of the files
(and have no commit privileges to the MW repository), the files we
modify are not within our purview to change (and understandably the MW
people wouldn't allow it even if we had commit privileges).

Is there any way to use the svn:externals property to solve the main
source issue? For example, could we point the revision we keep in our
main repository to the correct revision in the MW repository and then
tag the appropriate directories that contain the files we modify with
svn:external. These latter svn:external properties would name the
individual files we modify and point to the modified version that we
could keep in our repository. My concern is we are overloading the
files in the MW repository with files in our repository and I am not
sure subversion allows that.



There is a whole section in the svn book about this...

http://svnbook.red-bean.com/nightly/en/svn-

book.html#svn.advanced.vendorbr

BOb

I have read this section. It is about vendor drops, but it doesn't answer
the question I asked. Basically, we are doing a vendor drop now.

Dan



It actually does, but it's a bit hard to understand. Reread it carefully 
and you'll see that you actually track the public changes in a branch 
that you later merge back into your trunk.

Re: Getting error: 'Could not read response body: Secure connection truncated'

[Olivier Sannier]

David Aldrich wrote:
My suspicion is that the error is an indication of a timeout that 
happens because we use per-directory authorisation in Apache. I saw an 
article that suggested that setting SVNPathAuthz off in httpd.conf may 
fix this problem. Unfortunately, we must use per-directory 
authorisation because our project includes customer-confidential 
information that must be hidden from some teams.

I had similar problem and I believe the solution is in the list archive.

Add this to your location definition in the Apache config:

  LimitXMLRequestBody 0

http://httpd.apache.org/docs/2.2/mod/core.html#limitxmlrequestbody

Regards
Olivier

Re: question about Tree conflict: local edit, incoming delete upon merge

[Olivier Sannier]

emerson wrote:

emer...@emerson-desktop:~/workspace/branches/stable$ svn status
modules/com.company.search/src/java/com/company/search/api/response/DoRetrieveNatAdFeed.java
   C 
modules/com.company.search/src/java/com/company/search/api/response/DoRetrieveNatAdFeed.java
   local edit, incoming delete upon merge

why is that? This is a simple delete , why does it show as a conflict?
the file hasn't changed by any other revision that is part of the
merge. Shouldn't it just remove the file locally or mark it for
deletion? Can't I apply several revisions to commit afterwards
together if one of them contains a deletion??
   


The message says it all: You have a local (ie in trunk) modification 
while the merge tries to delete that modified files.
For you not to loose changes without knowing about it, SVN triggers a 
tree conflict. Only you, human, can decide what to do between keeping 
the file with the changes made in trunk, or accept the deletion that 
comes from the merge of the branch

Re: question about Tree conflict: local edit, incoming delete upon merge

[Olivier Sannier]

Between the time you created the branch and the time you merge it, the 
trunk has evolved and the file has been modified.

Use the log to see that.

Regards
Olivier

PS: Please reply to the list as well.

emerson wrote:

Hi Olivier

That is the thing, there is no changes done in that specific file!

I just did:
- revert that file
- update from svn, nothing to update
- merge that revision
- got conflict

One detail I left out: we are using 1.6 client and 1.4.4 server. Would
that be the reason of these type of conflicts?

Regards
Emerson
On 8 July 2010 12:34, Olivier Sannierobo...@free.fr  wrote:
   

emerson wrote:
 

emer...@emerson-desktop:~/workspace/branches/stable$ svn status

modules/com.company.search/src/java/com/company/search/api/response/DoRetrieveNatAdFeed.java
   C
modules/com.company.search/src/java/com/company/search/api/response/DoRetrieveNatAdFeed.java
 local edit, incoming delete upon merge

why is that? This is a simple delete , why does it show as a conflict?
the file hasn't changed by any other revision that is part of the
merge. Shouldn't it just remove the file locally or mark it for
deletion? Can't I apply several revisions to commit afterwards
together if one of them contains a deletion??

   

The message says it all: You have a local (ie in trunk) modification while
the merge tries to delete that modified files.
For you not to loose changes without knowing about it, SVN triggers a tree
conflict. Only you, human, can decide what to do between keeping the file
with the changes made in trunk, or accept the deletion that comes from the
merge of the branch


 


   

Re: Why is --reintegrate neccessary?

[Olivier Sannier]

Tino Schwarze wrote:

Hi there,

I've had a discussion with a collegue yesterday and he wondered why
--reintegrate is neccessary for reintegration merges at all. He supposed
SVN should be able to determine that the intended merge is a reintegrate
by looking at the mergeinfo.

So, this is just a question out of curiousity: Why is it neccessary to
specify --reintegrate? Or: In which case would a potential
auto-detection fail?

   

As always, the book is here for you:

http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

Re: Merge conflict markers... indicate what?

[Olivier Sannier]

Bob Archer wrote:

Bob Archer wrote:


Hi All,



I am doing our weekly merge from our release version project path
  

to


our new version development path. I am a bit confused at what the
conflict markers are showing me... here is the snippet of the
  

code


with the conflict markers:



 .working

If loBudgetCheck.OBMsg Is Nothing
  

Then


Exit For

End If

===

If Not loBudgetCheck.OBMsg Is
  

Nothing Then


.merge-right.r40712



What does this mean?  I expected to see the change made in the
  

target


as working and the change made in the source as right.



BOb

  

Working is what was on your hardrive (in your working copy) before
you
updated.
Merge right is what comes from the server, namely at revision 40712
You have to decide what version of the two you want to keep.




So basically what is between the  and the  is the diff between the base common rev and the working copy. And what is between the = and the  is the diff between the base common rev and the change in r40712? Is that correct? 

Yes


And if so... how does svn determine the common base rev?
It's written in the .svn folder that keeps track of the latest revision 
content, among other things.

Re: Size of SVN Transaction vs Actual commit size

[Olivier Sannier]

Ravi Roy wrote:

Actual commit size is 1.28 MB and this script gives me 5528 bytes.
 Something wrong with script or there is compression involved or what ?

Well, reading the book could have told you that this is expected:

http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.diskspace.deltas 

Re: Can we use relative paths in svn:externals propset?

[Olivier Sannier]

David Bartmess wrote:
I have two projects under a single repository, with A being dependent 
on B being checked out.


To set the svn:externals propset, can I use a relative path for the 
checkout directory for the depending (B) directory?


Such as :

svn propset svn:externals ../buildsupport 
http://URL/buildsupport/trunk BuildScripts


Will this work? I can't afford to try it on that repository since it's 
a live development repository... 

Maybe you can afford to read the manual, it explains all this...

Re: Tigris binary packages for Windows

[Olivier Sannier]

David Darj wrote:

On 2010-04-22 17:06, Cooke, Mark wrote:

Folks,

I am resurrecting this thread to ask if anyone has come forward to 
volunteer time and/or effort to resurrect the windoze binaries as we 
are still on 1.6.6 against 1.6.11 announced a few days ago.


In hope...

~ Mark C



I have built both 1.6.9 and 1.6.11
They are available on my webpage http://alagazam.net
You (and anyone else) is welcome to download and use it.
That's awesome. Many thanks for all this, it's a relief to see those 
packages available again.


The reason I've not announced the release in this (users) list is that 
I've hoped some people reading the dev list (where I did announce it) 
to download and test it first so I know my build environment is okey.
Ah, yes, I don't read the dev list, too many messages that I don't have 
a clue what they are talking about.


As the web page says all test on subversion itself is running ok., but 
the bindings has not been tested.
I don't use the bindings, but I just used the rest of it. It works just 
fine, couldn't see a problem with the package. It even installs on top 
of the previous ones, no need to uninstall before installing that one.


Once again, many thanks for this.
As far as I'm concerned, these packages are good to go and should be put 
forward on the SVN website pages.


Regards
Olivier

Re: Windows binaries for 1.6.9

[Olivier Sannier]

Chris Huseman wrote:

Hello,

I was wondering if the windows binary releases are still going to be 
maintained as they were for previous releases on tigris.org 
http://tigris.org?  I ask because the most recent version available 
there 
(http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=8100) is 
v1.6.6.


There was a discussion a month ago about this very subject which led to 
no definitive conclusion.
Basically, many people need those binaries, some even volunteered to 
create them but, from what I understand, no clear support was given to 
this initiative.

I'm not sure where it is at now.

Re: Tigris binary packages for Windows

[Olivier Sannier]

Troy Simpson wrote:

For base-level support, we narrowed that down to apache 2.2x.  Do we really
need to support all the python builds? They were a great service from D.J.
Heap, but now that we don't have that, do we really need to ditch all
windows builds?  What we could look at is a standard base-level windows
build that most people use.  Personally, I just use a windows client, as do
many users - I don't even use the apache bindings, nor do many windows
users.  We could leave specialised builds to teams who want to support them
which in theory would make the job at this end much easier.
   
Well, I, for one, would need the Apache 2.2 bindings but I do not need 
the Python bindings at all, which I suspect most users don't either.

So basic binaries with 2.2 support would be perfect for starters

Re: Tigris binary packages for Windows

[Olivier Sannier]

Geoff Rowell wrote:

sNop wrote on Wednesday, March 03, 2010 7:39 AM:
   

Well, I, for one, would need the Apache 2.2 bindings but I do not need
the Python bindings at all, which I suspect most users don't either.
So basic binaries with 2.2 support would be perfect for starters

   

The same, only need Apache 2.2 modules and compiled subversion, other
binding aren't so important for end user, which are useing subversion
  for versioning own projects.

And without installer! ;) Only copy to the Program Files and go on

 

Anyone who uses ViewVC for enhanced browsing of Subversion repositories will
be interested in the Python bindings.


Yes, of course.
The debate here is to find a minimal set of options to restart creating 
win32 builds. Once the minimal set works, it will be easier to add the 
rest of it.

Re: Managing Vendor Branches

[Olivier Sannier]

James Mansion wrote:

Jeff Mott wrote:

I've recently needed to track changes for vendor code drops, so I read
the SVN book's vendor branches chapter. But I'm not entirely happy
with part of the procedure, so I'd like to talk it out and, I hope,
find a better way.
I struggled with findinng a way to do this too. I can't help feeling 
that it is such a common
requirement that some bulletproof builtin automation would be 
worthwhile, and that there

be One True Way to do it.


There is the svn_load_dirs.pl script but it's not very intuitive to use.
For those who are under Windows, I wrote a wizard based tool that 
manages those externals for you.

Its sources (Delphi 2009) are available here:

http://svnwintools.tigris.org/svn/svnwintools/trunk/sources

along with a few other tools.
The tool in itself works well, I'm using it in production every time I 
have a new vendor drop.
The project's website at tigris is a whole other story as I did not have 
time to create it nor to publish precompiled binaries.


Regards
Olivier

Re: Tigris binary packages for Windows

[Olivier Sannier]

Bojan Resnik wrote:

Hi,
We have a custom server setup and we have been using Tigris.org 
binaries for Windows. The latest version there, however, is 1.6.6.
Will there be Tigris.org binary packages for Windows for Subversion 
1.6.9 and later? Or perhaps an equivalent of these packages, with full 
server, client and bindings but without installers?

I would be interested in those as well, please.

Regards
Olivier

Re: svn switch does not update relative externals

[Olivier Sannier]

Johan Corveleyn wrote:

On Mon, Feb 22, 2010 at 3:31 PM, Olivier Sannierobo...@free.fr  wrote:
   

I reread the svn book and it is not clear to me whether or not svn switch is
supposed to update a relative external.
To me it would be quite logical that it would, hence my surprise when I saw
the above behavior. Could it be that I missed something obvious?
 

I think this is a known bug. See
http://subversion.tigris.org/issues/show_bug.cgi?id=3390

It was recently fixed and proposed for backport to 1.6.x. It will
probably, hopefully, most likely, ... be included in 1.6.10.
   


Ah yes, you are right, this is exactly the same bug, don't know why I 
could not find it.

Well, let's hope it comes down in the next update to the 1.6 versions.

Regards
Olivier

Re: Reintegrate with vendor branches

[Olivier Sannier]

Ulrich Eckhardt wrote:

Check if while merging you omitted changing the mergeinfo in the 'libA'
folder. If so, that's probably a human error. Adding the missing info
manually is the right way to go.

Actually, the fact that merging to X changes the mergeinfo in subdir Y that
wasn't touched is a common source of confusion. There are two ways out:
  1. Educate the users. They must understand that these separate mergeinfo
properties are actually necessary. Yes, a better design could perhaps fix
that, but that is not the status quo.
   
Yes, that's pretty much the conclusion I came up to as well. I'll have 
to go around and tell the users to remember to commit everything. And I 
agree that a better design would help avoiding the confusion, even 
though I'm not sure what this design could look like.



  2. Merge to the root of the project only. This avoids having subdirs with
differing mergeinfos. This is a bit difficult in your project, because it
contains the libs which are otherwise on the same level, i.e. projects
themselves. What you should consider is not having copies of the libs in your
main project but references. The closest to the current state would be to use
svn:external to reference the libs. That way, the mergeinfo of both your
project and the external libs wouldn't be mixed but stay apart.
   
I can't use svn:external because I have local modifications that are not 
in the public versions of those libs.

In the end, I'll have to keep an eye on my users.

Regards
Olivier

Re: Reintegrate with vendor branches

[Olivier Sannier]

Olivier Sannier wrote:

Hello all,

Let's consider the following repository structure :

tags
branches
  feature1
trunk
  libs
libA
libB
  project1
vendors
  libA
current
  libB
current

The repository is at revision 100
libA and libB are external libraries managed as vendor branches which 
were merged twice each into the trunk since its beginning. This means 
that the following mergeinfo is on trunk/libs/libA :

/vendors/libA/current:25,30

and the following on trunk/libs/libB:
/vendors/libB/current:28,36

the feature1 branch was created as a copy of /trunk at revision 45 and 
changes from trunk were regularly merged into it which gives the 
following merge info on /branches/feature1:

/trunk:45-99

The last final merge from trunk being done in revision 100.
Now I want to reintegrate the feature branch back into trunk but I get 
the an error message saying that it is unable to reintegrate because 
some revisions are missing on the branch:


/branches/feature1/libs/libA is missing /trunk/libs/libA:45-99
/branches/feature1/libs/libB is missing /trunk/libs/libB:45-99

I don't understand why it complains as all changes are already in 
since they were merged before the feature branch was created.
Adding the above two paths and revision numbers in the merge infos for 
libA and libB allows to reintegrate but I would prefer if this could 
be avoided.

This was done with version 1.6.6 clients

Do you think this is a bug?
If yes, is it already reported and/or a fix available?
If not, what have I done wrong to get to this situation?

Regards
Olivier



I wonder if this message was seen, or if I missed some answers.
Does anyone have any clue?

Thanks
Olivier

Reintegrate with vendor branches

[Olivier Sannier]

Hello all,

Let's consider the following repository structure :

tags
branches
  feature1
trunk
  libs
libA
libB
  project1
vendors
  libA
current
  libB
current

The repository is at revision 100
libA and libB are external libraries managed as vendor branches which 
were merged twice each into the trunk since its beginning. This means 
that the following mergeinfo is on trunk/libs/libA :

/vendors/libA/current:25,30

and the following on trunk/libs/libB:
/vendors/libB/current:28,36

the feature1 branch was created as a copy of /trunk at revision 45 and 
changes from trunk were regularly merged into it which gives the 
following merge info on /branches/feature1:

/trunk:45-99

The last final merge from trunk being done in revision 100.
Now I want to reintegrate the feature branch back into trunk but I get 
the an error message saying that it is unable to reintegrate because 
some revisions are missing on the branch:


/branches/feature1/libs/libA is missing /trunk/libs/libA:45-99
/branches/feature1/libs/libB is missing /trunk/libs/libB:45-99

I don't understand why it complains as all changes are already in since 
they were merged before the feature branch was created.
Adding the above two paths and revision numbers in the merge infos for 
libA and libB allows to reintegrate but I would prefer if this could be 
avoided.

This was done with version 1.6.6 clients

Do you think this is a bug?
If yes, is it already reported and/or a fix available?
If not, what have I done wrong to get to this situation?

Regards
Olivier