[scm] Features that systems must support

[sebb <se...@gmail.com>]

Thought it might be worth recording some features which perhaps we
take for granted, but which may not be available in all systems.

Filenames.
As far as possible:
* the system should not restrict file name length
* the system should not restrict the characters used in filenames

OSes:
* servers should run on a reasonable range of OSes
* clients should run on a wider range of OSes
* system should not impose unnecessary restrictions on client-server
combinations (e.g. differing line-endings and file name syntax)

User Interface:
* command-line should be supported
* GUI should be supported
* (almost) all operations should be accessible through either GUI or
command-line

API:
* well-defined API that can be accessed from multiple languages

Filetypes:
* must be able to store text and binary files efficiently

===

(*) At one place where I worked, they had an expensive (and
feature-rich) SCM. It used special characters in file names in order
to distinguish versions. This meant that certain files could not be
stored in the system. Unfortunately the default separator character
they used was "-", which was also required for certain files on one of
the client OSes. We were unable to store these files; we ended up
having to put them in Zip files.

S///

Re: [scm] Features that systems must support

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Thu, Feb 28, 2008 at 2:53 AM, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> On Wed, Feb 27, 2008 at 4:41 PM, Jukka Zitting <ju...@gmail.com> wrote:
>  >  Good points, though I'd like to point out that we don't necessarily
>  >  need to live with just a single system. The points should apply to
>
>  As someone in another thread mentioned (probably Henri), the 'core'
>  ASF infrastructure team is *only* going to support one SCM.
>  Supporting multiple SCMs is simply not a viable option.

Agreed.

I wasn't suggesting that the official storage of our source code be
split across multiple systems. My point was that it might be (or
perhaps not) useful to provide people with for example read-only
mirrors of the source repository in other version control tools. For
example (and I'm just throwing ideas here) it might be nice to have a
hierarchy of repository mirrors that things like CI tools could use
without putting excessive load on the central Subversion repository.

Such auxiliary systems wouldn't IMHO need to support as strict
baseline feature requirements as the canonical Apache version control
system.

BR,

Jukka Zitting

Re: [scm] Features that systems must support

[Justin Erenkrantz <ju...@erenkrantz.com>]

On Wed, Feb 27, 2008 at 4:41 PM, Jukka Zitting <ju...@gmail.com> wrote:
>  Good points, though I'd like to point out that we don't necessarily
>  need to live with just a single system. The points should apply to

As someone in another thread mentioned (probably Henri), the 'core'
ASF infrastructure team is *only* going to support one SCM.
Supporting multiple SCMs is simply not a viable option.  As I also
said in another post on another list, we're not going to have
fragmented SCMs; so if we decide to go to another SCM, every Apche
project is coming along for the ride whether they like it or not.
There may be a period of migration, but having project A use SCM X and
another ASF project use a different SCM is unacceptable.  -- justin

Re: [scm] Features that systems must support

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Wed, Feb 27, 2008 at 8:28 PM, sebb <se...@gmail.com> wrote:
> Thought it might be worth recording some features which perhaps we
> take for granted, but which may not be available in all systems.

Good points, though I'd like to point out that we don't necessarily
need to live with just a single system. The points should apply to
anything like our central Subversion repository, but we could well
support alternative client tools like git-svn or perhaps even have the
repository mirrored in other scm server tools with less strict
requirements for the supported features.

Doing something like that might not be reasonable, but I wouldn't shut
out options by requiring that any system that we consider supporting
should be ready to replace the central Subversion repository. There
could well be smaller scale and more tightly scoped scenarios where
extra tools could be used to augment the Subversion features.

BR,

Jukka Zitting

Re: [scm] Features that systems must support

[Steve Loughran <st...@apache.org>]

Justin Erenkrantz wrote:
> On Wed, Feb 27, 2008 at 10:28 AM, sebb <se...@gmail.com> wrote:
>>  * servers should run on a reasonable range of OSes
> 
> I'll go so far and say as long as it runs on FreeBSD, we're happy.
> 
>>  * clients should run on a wider range of OSes
> 
> I think it *must* run on all *nix variants and Windows.  Dropping
> Windows support I think is a non-starter.  Or, are we willing to say
> we'll drop Windows support?
> 
>>  * command-line should be supported
>>  * GUI should be supported
> 
> What type of GUIs?  What about integration with IDEs?  Eclipse?
> IntelliJ?  Are we okay with losing IDE support?  Or, take the opinion
> that if we switch, they'll eventually add support - this is what we
> saw with Subversion, but maybe we can convince folks to lose their IDE
> integration for a few years while the downstream IDE developers play
> catch up.  -- justin

I think IDE integration w/ SVN has got so good you'd be hard pressed to 
justify the move, especially for the java developers, where IDEs do 
integrate well.

steve

Re: [scm] Features that systems must support

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Thu, Feb 28, 2008 at 1:02 PM, Santiago Gala <sa...@gmail.com> wrote:
>  In use cases where the only tools used are client side tools, but the
>  global group workflow is not changed, each potential user chooses what
>  to use and what not. This was the only meaning of my comment.

Exactly, and that's how I understood you. We're looking for ways to
enable and support new choices and alternatives, not taking away
existing features.

BR,

Jukka Zitting

Re: [scm] Features that systems must support

[Santiago Gala <sa...@gmail.com>]

El jue, 28-02-2008 a las 02:43 +0200, Jukka Zitting escribió:
> Hi,
> 
> On Thu, Feb 28, 2008 at 12:35 AM, Davanum Srinivas <da...@gmail.com> wrote:
> >  Please don't drop support for Windows.
> 
> I don't think anyone is seriously considering dropping any functionality.
> 
> So far at least I'm only looking at ways to have more, not less, functionality.
> 

Of course. The point of my comment is that if *I* plan to use, for
instance git-svn to track a subversion repository locally, *I* don't
need to care about windows. Other people will just stay using subversion
or their favorite tool, be it svk, hg-svn, eclipse plugins, whatever. As
the community interaction will always take place either via svn commits
or via patches, the tools doesn't really matter.

In use cases where the only tools used are client side tools, but the
global group workflow is not changed, each potential user chooses what
to use and what not. This was the only meaning of my comment.

Regards
Santiago

> BR,
> 
> Jukka Zitting
-- 
Santiago Gala
http://memojo.com/~sgala/blog/

Re: [scm] Features that systems must support

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Thu, Feb 28, 2008 at 12:35 AM, Davanum Srinivas <da...@gmail.com> wrote:
>  Please don't drop support for Windows.

I don't think anyone is seriously considering dropping any functionality.

So far at least I'm only looking at ways to have more, not less, functionality.

BR,

Jukka Zitting

Re: [scm] Features that systems must support

[Davanum Srinivas <da...@gmail.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Please don't drop support for Windows. Though am ok if there are no GUI's at all.

thanks,
dims

Santiago Gala wrote:
| El mié, 27-02-2008 a las 10:52 -0800, Justin Erenkrantz escribió:
|> On Wed, Feb 27, 2008 at 10:28 AM, sebb <se...@gmail.com> wrote:
|>>  * servers should run on a reasonable range of OSes
|> I'll go so far and say as long as it runs on FreeBSD, we're happy.
|>
|>>  * clients should run on a wider range of OSes
|> I think it *must* run on all *nix variants and Windows.  Dropping
|> Windows support I think is a non-starter.  Or, are we willing to say
|> we'll drop Windows support?
|>
|
| It all depends on use cases. It is not the same a tool I use to track
| our current subversion setup for disconnected operation that switching
| the whole ASF to it. I mean, I don't ever use windows, so I really don't
| care personally about windows support. Obviously people that wants to
| track a "vendor branch" while merging frequently, and contributing back
| patches, will for sure care about what they install if they have windows
| deployed.
|
| So, while I'd say it is important to have the widest possible coverage,
| I'd just document the status quo and ongoing efforts.
|
|>>  * command-line should be supported
|>>  * GUI should be supported
|> What type of GUIs?  What about integration with IDEs?  Eclipse?
|> IntelliJ?  Are we okay with losing IDE support?  Or, take the opinion
|> that if we switch, they'll eventually add support - this is what we
|> saw with Subversion, but maybe we can convince folks to lose their IDE
|> integration for a few years while the downstream IDE developers play
|> catch up.  -- justin
|
| Most "modern" dSCMs have rudimentary IDE support, if any. git has a (i'd
| say alpha) eclipse plugin.
|
|
| Regards
| Santiago
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)

iD8DBQFHxeXHgNg6eWEDv1kRAv6+AJwPt1IfGrpOzW/poSnGn+en4IjzMQCfeWCY
CHezyxfk7uYPqcx2A1x9Cho=
=KEM+
-----END PGP SIGNATURE-----

Re: [scm] Features that systems must support

[Santiago Gala <sa...@gmail.com>]

El mié, 27-02-2008 a las 10:52 -0800, Justin Erenkrantz escribió:
> On Wed, Feb 27, 2008 at 10:28 AM, sebb <se...@gmail.com> wrote:
> >  * servers should run on a reasonable range of OSes
> 
> I'll go so far and say as long as it runs on FreeBSD, we're happy.
> 
> >  * clients should run on a wider range of OSes
> 
> I think it *must* run on all *nix variants and Windows.  Dropping
> Windows support I think is a non-starter.  Or, are we willing to say
> we'll drop Windows support?
> 

It all depends on use cases. It is not the same a tool I use to track
our current subversion setup for disconnected operation that switching
the whole ASF to it. I mean, I don't ever use windows, so I really don't
care personally about windows support. Obviously people that wants to
track a "vendor branch" while merging frequently, and contributing back
patches, will for sure care about what they install if they have windows
deployed.

So, while I'd say it is important to have the widest possible coverage,
I'd just document the status quo and ongoing efforts. 

> >  * command-line should be supported
> >  * GUI should be supported
> 
> What type of GUIs?  What about integration with IDEs?  Eclipse?
> IntelliJ?  Are we okay with losing IDE support?  Or, take the opinion
> that if we switch, they'll eventually add support - this is what we
> saw with Subversion, but maybe we can convince folks to lose their IDE
> integration for a few years while the downstream IDE developers play
> catch up.  -- justin

Most "modern" dSCMs have rudimentary IDE support, if any. git has a (i'd
say alpha) eclipse plugin. 


Regards
Santiago


-- 
Santiago Gala
http://memojo.com/~sgala/blog/

Re: [scm] Features that systems must support

[Justin Erenkrantz <ju...@erenkrantz.com>]

On Wed, Feb 27, 2008 at 10:28 AM, sebb <se...@gmail.com> wrote:
>  * servers should run on a reasonable range of OSes

I'll go so far and say as long as it runs on FreeBSD, we're happy.

>  * clients should run on a wider range of OSes

I think it *must* run on all *nix variants and Windows.  Dropping
Windows support I think is a non-starter.  Or, are we willing to say
we'll drop Windows support?

>  * command-line should be supported
>  * GUI should be supported

What type of GUIs?  What about integration with IDEs?  Eclipse?
IntelliJ?  Are we okay with losing IDE support?  Or, take the opinion
that if we switch, they'll eventually add support - this is what we
saw with Subversion, but maybe we can convince folks to lose their IDE
integration for a few years while the downstream IDE developers play
catch up.  -- justin