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
<juergen.sauerm...@t-online.de <mailto:juergen.sauerm...@t-online.de>>
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"
<juergen.sauerm...@t-online.de
<mailto:juergen.sauerm...@t-online.de>> 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
