Re: [Bug-apl] Version control

[Juergen Sauermann]

Hi,

I see. I also worked with several VCS and my favorite is still RCS.
I just think that changing a VCS in the middle of something is just extra work.
And I am admittedly not as familiar with git or mercurial as with SVN.

/// Jürgen


On 04/13/2014 05:51 PM, Elias Mårtenson wrote:

Sure, that works fine. The reason I was suggesting a shift to a distributed system (Savannah supports at least Bazaar, Mercurial and Git, as far as I know) was that the local-vs-official repository can be handled more smoothly that way.

However, I do not want to be "that guy". You know, the guy who keeps advocating his favourite version control system. I personally have absolutely no problem with any VCS, as long as the workflow can be smooth. :-)

Regards,

Elias

On 13 April 2014 23:46, Juergen Sauermann <address@hidden> wrote:

Hi,

my concern is not the ultimate responsibility because if we get more and more sub-projects then
I would NOT like to be responsible for the merges. I would prefer if the responsibilities are agreed
beforehand and then every contributor would have, say, her subdirectory and with it also the
responsibility in terms of maintenance and documentation for that subdirectory.

As a GNU maintainer I would also think that the sources should be hosted by the GNU project in the
first place, and that the GNU policies should be followed. I would also like to mention that so far
GNU savannah worked very well for me and that the guys behind it are very responsive when it
comes to problems. And many current GNU APL users follow the main GNU APL SVN - why should we
change that?

That does not prevent a local repository for development. I have my own local SVN (the 6000+ numbers
on the GNU APL welcome screen are my local SVN numbers). A commit to the remote GNU APL SVN
repository is only made after a local build, debian packaging, and RPM packaging has succeeded (see
make EXPO on top-level), I believe we should do something similar for the sub-projects.

/// Jürgen

On 04/13/2014 04:56 PM, Elias Mårtenson wrote:

Another option would be to use a distributed VC like Mercurial or Git. Then you'd still be ultimately responsible for all merges into mainline, with contributors being able to work on off-site branches.

Regards,
Elias

On 13 Apr 2014 22:52, "Juergen Sauermann" <address@hidden> wrote:

Hi Elias,

yes, you have a point there. My first guess would be GNU savannah where
GNU APL lives. We would have to figure a few things like how to change SVN permissions,
paperwork for contributors (as per http://www.gnu.org/prep/maintain/maintain.html) and so
on, but that is doable.

Another point is packaging and testing if all works together. Normally I test the core GNU APL automatically
before committing into the SVN at savannah. Something similar should happen for those sub-projects that we
see as essential; we can be a bit more relaxed for demo projects.

/// Jürgen


On 04/13/2014 03:55 PM, Elias Mårtenson wrote:

There are now a few separate side-projects that all depend on and integrate with GNU APL:

• Emacs mode
• Thomas' _javascript_ port
• SQL API
• Possible Android port?

These ports are spread over different source repositories (I'm not even sure where I can find the _javascript_ port) it's getting a bit messy, and I can only imagine the pain if Jürgen decides to actually integrate this port into the mainline.

As for myself, keeping my github-based repository in sync with the mainline is manageable, but not as smooth as it could be.

Because of this, would it make sense to migrate the repository to a distributed system? I personally don't care which one, but being able to work with the same repository as Jürgen would be very nice.

Regards,

Elias