In the light of problems with SVN on dsource, the Bindings project has been migrated to GitHub on a trial basis.  Apparently this is more or less the last "active" project on Dsource, so after a brief discussion on another thread I have decided to give it a try.

So it's now at:

https://github.com/smjgordon/bindings

Please don't confuse this with dsource-bindings, which is an automatically updated mirror of the Dsource project.  The one I have linked to is a new repository on GitHub which may become the live repository for the Bindings project.

For those of you who are still unfamiliar with GitHub, it's a Subversion repository just like we had on dsource, so you don't need to learn a new way of working or obtain any new tools - you just need to set up a GitHub account if you don't have one already.

Could people please try checking out the project on GitHub, and committing a change? There's still plenty of work to do on WindowsAPI so you could do some of the work there. (The wiki is broken at the moment, so I don't recommend trying to edit the module list there, but as a temporary measure you could just post on this thread if you're going to do some major work on one or more of the files.)

Failing that, there's a file test.txt (directly under trunk) which you could make a dummy edit to.  But whatever you do, please be sure to reply to this thread to let me know whether or not you could commit successfully.

If the decision is made to relocate Bindings permanently to GitHub, the wiki pages will be migrated in due course.

Stewart.

-- 
My email address is valid but not my primary mailbox and not checked regularly.  Please keep replies on the 'group where everybody may benefit.

On Sunday, 19 April 2015 at 23:14:13 UTC, Stewart Gordon wrote:
> For those of you who are still unfamiliar with GitHub,

Stewart, I haven't seen an active D project that WASN'T hosted on GitHub for years now.

> Could people please try checking out the project on GitHub, and committing a change?

Git commits are local, and will always succeed. I'm guessing you actually want to allow anyone to push their commits to your repository, which is not how collaboration on GitHub works. You may want to read up on pull requests:

https://help.github.com/articles/using-pull-requests/

I'm sorry about the Dsource malfunctions. When I took over hosting, my goal was to archive it in a read-only state. The move has eaten much more of my time than I have anticipated, because it depends so much on ancient software that is difficult to get running these days short of making a virtual machine.

> There's still plenty of work to do on WindowsAPI so you could do some of the work there. (The wiki is broken at the moment, so I don't recommend trying to edit the module list there, but as a temporary measure you could just post on this thread if you're going to do some major work on one or more of the files.)

The module list has no value these days. Most people in that list no longer use D. Git allows quickly checking the history of any one file. Contributions to the project itself have been so few that it makes no sense to partition out module ownership.

> If the decision is made to relocate Bindings permanently to GitHub, the wiki pages will be migrated in due course.

Given that SVN is going the way of RCS and CVS, it's not really an "if".

On Sunday, 19 April 2015 at 23:37:58 UTC, Vladimir Panteleev wrote:
> On Sunday, 19 April 2015 at 23:14:13 UTC, Stewart Gordon wrote:
>> For those of you who are still unfamiliar with GitHub,
>
> Stewart, I haven't seen an active D project that WASN'T hosted on GitHub for years now.

There's a few on bitbucket.

On 20/04/2015 00:37, Vladimir Panteleev wrote:
> On Sunday, 19 April 2015 at 23:14:13 UTC, Stewart Gordon wrote:
>> For those of you who are still unfamiliar with GitHub,
>
> Stewart, I haven't seen an active D project that WASN'T hosted on GitHub for years now.

That doesn't mean absolutely none of us are just doing personal projects which we keep on our own computers.

>> Could people please try checking out the project on GitHub, and committing a change?
>
> Git commits are local, and will always succeed.

I committed some updates the other day and they seem they have gone straight into the online repository.

> I'm guessing you actually want to allow
> anyone to push their commits to your repository, which is not how collaboration on GitHub
> works. You may want to read up on pull requests:
>
> https://help.github.com/articles/using-pull-requests/

That mentions a 'shared repository model'.  What is that if not a way of enabling any user to push changes?  (That said, it isn't clear at the moment how to control whether a given repository is fork-pull or shared, or even whether the distinction is at the repository setup level or some other.)

It's too late in the day for me to take much in at the moment, but another page I've found
http://stackoverflow.com/questions/5010754/github-collaborators-have-commit-access
seems to say that, if I make somebody a 'collaborator', then that somebody will be able to commit to my repository.

<snip>
> The module list has no value these days. Most people in that list no longer use D.

?? The module list is a list of modules, not a list of people.

> Git allows quickly checking the history of any one file. Contributions to the project itself
> have been so few that it makes no sense to partition out module ownership.

That isn't the sole purpose of the module list.  It also serves to document the status of each file.

>> If the decision is made to relocate Bindings permanently to GitHub, the wiki pages will
>> be migrated in due course.
>
> Given that SVN is going the way of RCS and CVS, it's not really an "if".

What do you mean by this?

Stewart.

-- 
My email address is valid but not my primary mailbox and not checked regularly.  Please keep replies on the 'group where everybody may benefit.

On Monday, 20 April 2015 at 22:57:51 UTC, Stewart Gordon wrote:
> I committed some updates the other day and they seem they have gone straight into the online repository.

Committing is a local (non-network) operation in git, so you must have pushed them afterwards, or your GUI has done this for you.

>> https://help.github.com/articles/using-pull-requests/
>
> That mentions a 'shared repository model'.  What is that if not a way of enabling any user to push changes?  (That said, it isn't clear at the moment how to control whether a given repository is fork-pull or shared, or even whether the distinction is at the repository setup level or some other.)

The shared repository model rarely applies to open-source projects, and I don't think it applies to the bindings project.

>> The module list has no value these days. Most people in that list no longer use D.
>
> ?? The module list is a list of modules, not a list of people.

Sorry, I was talking about the "Assigned to" column. I was misremembering, I agree it might be worth migrating to the GitHub wiki.

>> Given that SVN is going the way of RCS and CVS, it's not really an "if".
>
> What do you mean by this?

SVN use, especially in open-source projects, has heavily declined in the past years. People have begun maintaining their own forks and mirrors of the bindings project just so they wouldn't have to muck with SVN. The bindings project needs to move away from SVN if it is to avoid fragmentation and be friendly to contributions.

On 2015-04-21 01:42, Vladimir Panteleev wrote:

> Committing is a local (non-network) operation in git, so you must have
> pushed them afterwards, or your GUI has done this for you.

Just for the record, it is possible to use SVN to interact with repositories on Github [1], including committing.

https://help.github.com/articles/support-for-subversion-clients/

-- 
/Jacob Carlborg

On Monday, 20 April 2015 at 23:42:54 UTC, Vladimir Panteleev wrote:
> On Monday, 20 April 2015 at 22:57:51 UTC, Stewart Gordon wrote:
>> I committed some updates the other day and they seem they have gone straight into the online repository.
>
> Committing is a local (non-network) operation in git, so you must have pushed them afterwards, or your GUI has done this for you.

I think he's using github's svn support The repository is still a git repository.

On 21/04/2015 00:42, Vladimir Panteleev wrote:
<snip>
> Committing is a local (non-network) operation in git, so you must have pushed them
> afterwards, or your GUI has done this for you.

I committed using TortoiseSVN.  Would that auto-push?  I never imagined so.

<snip>
> The shared repository model rarely applies to open-source projects, and I don't think it
> applies to the bindings project.

Empty comments like "I don't think" don't help any of us.  We need to try and figure out whether it applies, and if not then how to make it apply.

<snip>
> SVN use, especially in open-source projects, has heavily declined in the past years.
> People have begun maintaining their own forks and mirrors of the bindings project

Who are these people?

> just so they wouldn't have to muck with SVN.

How is mucking with SVN a burden?  It takes only either a one-line command line invocation or a few mouse clicks to update or commit.  It seems to me that if people are maintaining their own forks then it's more likely to be because they want the additions they make all to themselves for their personal projects, rather than to contribute to the project.

> The bindings project needs to move away from SVN if
> it is to avoid fragmentation and be friendly to contributions.

How does using SVN lead to "fragmentation"?  I don't understand.

Stewart.

-- 
My email address is valid but not my primary mailbox and not checked regularly.  Please keep replies on the 'group where everybody may benefit.

On Tuesday, 21 April 2015 at 21:31:39 UTC, Stewart Gordon wrote:
> On 21/04/2015 00:42, Vladimir Panteleev wrote:
> <snip>

I'm sorry but someone else will need to take over here. With all due respect for the work you've done so far, I simply don't have the time or energy to catch you up with the past decade's advances in software development and version control. There is a lot of information available online about how to use Git and GitHub, as well as a lot of existing discussions on modern best practices for open-source projects - reiterating these in this thread is a waste of everyone's resources.

By the way, SVN support on github.com was announced on April 1, 2010 - half feature, half April Fools' joke.

On Tuesday, 21 April 2015 at 21:31:39 UTC, Stewart Gordon wrote:
> How does using SVN lead to "fragmentation"?  I don't understand.

See http://forum.dlang.org/post/mailman.3160.1418550079.9932.digitalmars-d@puremagic.com