Re: Git vs SVN (was: Can we improve things?)

[Federico Mena Quintero]

On Sat, 2007-09-08 at 06:26 -0700, Sanford Armstrong wrote:
> I know their are a few random blog posts floating around, but I'd like
> to see something on l.g.o that documents the suggested workflow for
> git-svn/bzr-svn/hg-svn/etc.  Is it really a passable solution to all
> this?  Does it help regular contributors without SVN accounts in a
> concrete way?

Glad you asked :)

http://live.gnome.org/GitForGnomeDevelopers

  Federico

___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Creating new modules (was Re: Git vs SVN (was: Can we improve things?))

[Kevin Kubasik]

I often just sit in #commits on irc.gnome.org...

Works pretty well for me :)

Cheers,
Kevin Kubasik

On 9/11/07, Paolo Borelli <[EMAIL PROTECTED]> wrote:
>
> Il giorno lun, 10/09/2007 alle 17.40 -0400, Claudio Saavedra ha scritto:
> > On Mon, 2007-09-10 at 17:01 -0400, Havoc Pennington wrote:
> > >
> > > Then the daily summary could be in the planet gnome feed, perhaps.
> > >
> > > I don't know, I'm sure there are better solutions, and it's academic
> > > unless someone turns up who decides to try and code something. Just
> > > throwing out ideas.
> >
>
> I totally second the feeling that we are currently missing something
> that allows to keep an eye on all the GNOME commits.
> When we were on CVS I used to use bonsai go get a webpage with all
> commits in the last 24 hours and skim through it to see if anything
> interesting happened.
>
> > CIA.vc already provides some access to this information in a standard
> > way.
> >
> > For instance,
> >
> > http://cia.vc/stats/project/gnome/.rss for all the commits going in
>
>
> I am using this, but it's far from what I liked in the old setup: first
> of all in bonsai I was just one click away from the actual patch, so
> that I could see the real change in case something looked interesting.
> Now I have to manually use viewcvs, which makes it way less frequent:
> for instance it happened more than once that I spotted a bug or a typo
> by reviewing committed diff in bonsai, this has not happened anymore
> since I just go through the pain of looking at a diff in viewcvs only in
> rare cases.
>
> Beside CIA feeds are not 100% reliable and they seem to drop commits
> sometimes so I cannot use the feeds to see if something was committed to
> my modules.
>
> Paolo
>
>
> ___
> foundation-list mailing list
> foundation-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/foundation-list
>


-- 
Cheers,
Kevin Kubasik
http://kubasik.net/blog
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Creating new modules (was Re: Git vs SVN (was: Can we improve things?))

[Paolo Borelli]

Il giorno lun, 10/09/2007 alle 17.40 -0400, Claudio Saavedra ha scritto:
> On Mon, 2007-09-10 at 17:01 -0400, Havoc Pennington wrote:
> > 
> > Then the daily summary could be in the planet gnome feed, perhaps.
> > 
> > I don't know, I'm sure there are better solutions, and it's academic
> > unless someone turns up who decides to try and code something. Just
> > throwing out ideas. 
> 

I totally second the feeling that we are currently missing something
that allows to keep an eye on all the GNOME commits.
When we were on CVS I used to use bonsai go get a webpage with all
commits in the last 24 hours and skim through it to see if anything
interesting happened.

> CIA.vc already provides some access to this information in a standard
> way.
> 
> For instance, 
> 
> http://cia.vc/stats/project/gnome/.rss for all the commits going in


I am using this, but it's far from what I liked in the old setup: first
of all in bonsai I was just one click away from the actual patch, so
that I could see the real change in case something looked interesting.
Now I have to manually use viewcvs, which makes it way less frequent:
for instance it happened more than once that I spotted a bug or a typo
by reviewing committed diff in bonsai, this has not happened anymore
since I just go through the pain of looking at a diff in viewcvs only in
rare cases.

Beside CIA feeds are not 100% reliable and they seem to drop commits
sometimes so I cannot use the feeds to see if something was committed to
my modules.

Paolo


___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Creating new modules (was Re: Git vs SVN (was: Can we improve things?))

[Jeff Waugh]

> Bringing it back to the present, there's stuff on svn.mugshot.org that
> really belongs on gnome.org, but it seems it didn't end up there. I don't
> think this was a conscious thing, but I think it probably was due to just
> enough of a barrier to create a new gnome module.

This happens with more than just revision control infrastructure. More and
more projects are hosting everything (web, svn, lists) elsewhere, because of
the social and technical issues related to staying upstream -- it's not just
infrastructure (though your example is probably the strongest atm).

Anyway, this warrants a lot of thought.

- Jeff

-- 
linux.conf.au 2008: Melbourne, Australiahttp://lca2008.linux.org.au/
 
 "Again you are making up inventing as you go. Be specific aba gaba
 datata." - Oscar Plameras
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Jeff Waugh]

> $ bzr init-repo --trees some-project
> $ cd some-project
> $ bzr checkout http://url/to/some-project
> $ bzr branch mainline working
> $ cd working
> $ ./configure
> $ make
> 
> ...compared to the same steps using svn...
> 
> $ svn co http://url/to/some-project/trunk some-project
> $ cd some-project
> $ ./configure
> $ make

You appear to be comparing completely different things. If you want to do a
checkout with bzr:

$ bzr co http://url/to/some-project/trunk some-project
$ cd some-project
$ ./configure
$ make

If you want to have a branch with bzr:

$ bzr branch http://url/to/some-project/trunk some-project
$ cd some-project
$ ./configure
$ make

Same.

- Jeff

-- 
GNOME.conf.au 2008: Melbourne, Australia http://live.gnome.org/Melbourne2008
 
o/~ we all live in a yellow subroutine o/~ - auspex
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Curtis Hovey]

On Mon, 2007-09-10 at 16:41 -0700, Sanford Armstrong wrote:
> On 9/8/07, Jeff Waugh <[EMAIL PROTECTED]> wrote:
> > 
> >
> > > I simply meant that less people are familiar with D-SCM tools and that
> > > they are somewhat harder for a newbie to learn than C-SCM tools.
> >
> > This is an unfortunate cultural relic created by arch/tla, and hilariously
> > promulgated by git. Sure, fewer people are familiar with them, but the good
> > ones are not harder to learn.
> 
> I'm not really talking about the UI of the D-SCM tool, but about some
> fundamentals of the distributed model.  Getting code and pushing code
> seems to always require an additonal step.  Users have to learn about
> branching and merging up front, whereas in SVN this would come later
> in their education.  If I were a newbie developer I would find this
> confusing.  As I've stated, I don't have much experience with D-SCM,
> but these are the instructions to get started hacking on one project
> using bzr...
> 
> $ bzr init-repo --trees some-project
> $ cd some-project
> $ bzr checkout http://url/to/some-project
> $ bzr branch mainline working
> $ cd working
> $ ./configure
> $ make

Maybe there is. I'm not certain I would want to check something out.
That is the same workflow problem this thread is discussing.


Just skip the checkout, branch, make lots of changes and commits
(uncommits, shelves, unshelves, and merges) until you are sure you have
something that someone else is interested in. after pushing the changes
to a public place. Ask the third party for review, and that party could
do the merge and commit. If your very privileged, you can do the merge
into mainline and commit yourself.

> ...compared to the same steps using svn...
> 
> $ svn co http://url/to/some-project/trunk some-project
> $ cd some-project
> $ ./configure
> $ make
> 
> There's just a higher cognitive investment for a newbie getting
> started with D-SCM.  As bzr/git/etc become more common in the FLOSS
> communities, this won't be as much of an issue, though.  And the
> advantages of the distributed model have been well covered here.  :-)


The initial investment for both is still conceptional, and it takes the
same amount of time. The only people who have a higher investment are
people learning multiple workflows. Everyone working with versioning
systems needs to understand repositories, where the code is, how to get
it, how to record/report their changes, and how to publish.

D-SCM benefits people who are not the maintainers, or are offline
frequently. The project maintainers remain in authority to oversee
oversee and accept changes. The advantage is that developers who are not
in authority can exchange and collaborate on a project without special
(and possibly dangerous) power. When their work is good enough for
mainline, it can be accepted by the maintainers. D-SCM provides a
workflow for non-privileged users to achieve more in the time they have
to contribute.

-- 

__C U R T I S  C.  H O V E Y___
Guilty of stealing everything I am.


signature.asc
Description: This is a digitally signed message part
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Lucas Rocha]

Hi,

I hate to do this but... again... please move this discussion to a
more appropriate mailing list like d-d-l or gnome-infrastructure.

Thanks,

--lucasr


2007/9/11, Sanford Armstrong <[EMAIL PROTECTED]>:
> On 9/8/07, Jeff Waugh <[EMAIL PROTECTED]> wrote:
> > 
> >
> > > I simply meant that less people are familiar with D-SCM tools and that
> > > they are somewhat harder for a newbie to learn than C-SCM tools.
> >
> > This is an unfortunate cultural relic created by arch/tla, and hilariously
> > promulgated by git. Sure, fewer people are familiar with them, but the good
> > ones are not harder to learn.
>
> I'm not really talking about the UI of the D-SCM tool, but about some
> fundamentals of the distributed model.  Getting code and pushing code
> seems to always require an additonal step.  Users have to learn about
> branching and merging up front, whereas in SVN this would come later
> in their education.  If I were a newbie developer I would find this
> confusing.  As I've stated, I don't have much experience with D-SCM,
> but these are the instructions to get started hacking on one project
> using bzr...
>
> $ bzr init-repo --trees some-project
> $ cd some-project
> $ bzr checkout http://url/to/some-project
> $ bzr branch mainline working
> $ cd working
> $ ./configure
> $ make
>
> ...compared to the same steps using svn...
>
> $ svn co http://url/to/some-project/trunk some-project
> $ cd some-project
> $ ./configure
> $ make
>
> There's just a higher cognitive investment for a newbie getting
> started with D-SCM.  As bzr/git/etc become more common in the FLOSS
> communities, this won't be as much of an issue, though.  And the
> advantages of the distributed model have been well covered here.  :-)
>
> Sandy
> ___
> foundation-list mailing list
> foundation-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/foundation-list
>
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Sanford Armstrong]

On 9/8/07, Jeff Waugh <[EMAIL PROTECTED]> wrote:
> 
>
> > I simply meant that less people are familiar with D-SCM tools and that
> > they are somewhat harder for a newbie to learn than C-SCM tools.
>
> This is an unfortunate cultural relic created by arch/tla, and hilariously
> promulgated by git. Sure, fewer people are familiar with them, but the good
> ones are not harder to learn.

I'm not really talking about the UI of the D-SCM tool, but about some
fundamentals of the distributed model.  Getting code and pushing code
seems to always require an additonal step.  Users have to learn about
branching and merging up front, whereas in SVN this would come later
in their education.  If I were a newbie developer I would find this
confusing.  As I've stated, I don't have much experience with D-SCM,
but these are the instructions to get started hacking on one project
using bzr...

$ bzr init-repo --trees some-project
$ cd some-project
$ bzr checkout http://url/to/some-project
$ bzr branch mainline working
$ cd working
$ ./configure
$ make

...compared to the same steps using svn...

$ svn co http://url/to/some-project/trunk some-project
$ cd some-project
$ ./configure
$ make

There's just a higher cognitive investment for a newbie getting
started with D-SCM.  As bzr/git/etc become more common in the FLOSS
communities, this won't be as much of an issue, though.  And the
advantages of the distributed model have been well covered here.  :-)

Sandy
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Creating new modules (was Re: Git vs SVN (was: Can we improve things?))

[Federico Mena Quintero]

On Mon, 2007-09-10 at 16:42 -0400, Havoc Pennington wrote:

> Anyway. I'm not sure the old cvs-commits-list type approach really
> scales to GNOME's current size, but I think something *was* lost.

Yes, something definitely was lost.  It was quite pleasant to see commit
messages go by; people cared enough that you'd see jokes and funny stuff
deliberately written for the commit messages.

Then it became a firehose as the project grew larger.  I do miss reading
commit logs and wouldn't mind doing it for a few sub-projects, but
definitely not for all of GNOME.

  Federico

___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Creating new modules (was Re: Git vs SVN (was: Can we improve things?))

[Claudio Saavedra]

On Mon, 2007-09-10 at 17:01 -0400, Havoc Pennington wrote:
> 
> Then the daily summary could be in the planet gnome feed, perhaps.
> 
> I don't know, I'm sure there are better solutions, and it's academic
> unless someone turns up who decides to try and code something. Just
> throwing out ideas. 

CIA.vc already provides some access to this information in a standard
way.

For instance, 

http://cia.vc/stats/project/gnome/.rss for all the commits going in
http://cia.vc/stats/project/gnome/eog/.rss for all the commits in EOG
http://cia.vc/stats/author/csaavedra/.rss for all my commits, 

etc.

Claudio

-- 
Claudio Saavedra  <[EMAIL PROTECTED]>

Día del Software Libre, Curicó  http://curico.diadelsoftwarelibre.cl

___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Olav Vitters]

On Mon, Sep 10, 2007 at 03:05:18PM -0500, Federico Mena Quintero wrote:
> On Sat, 2007-09-08 at 10:17 +0200, Olav Vitters wrote:
> 
> Hi, Olav,
> 
> > You are ignoring the central place. You need somewhere all GNOME devs
> > are able to commit. This is what is so wrong about
> > www.gnome.org/~foo/git/.
> 
> The interesting question is, "why are people doing ~foo/git/blah in the
> first place?"

Oh, only reading this email after the one from HP.

> Because it is no longer possible to create new SVN modules easily, as it
> was when we used CVS.  By "easily" I mean that it you want to create a
> module, you don't need to ask anyone to do it for you.

So ehr, we should have svn.gnome.org/svn/testingground ?
(or whatever?)

> Think of a gnome.org developer who has just written a new and exciting
> program, and wants to make it available.  You are in that beautiful
> moment when the program works well enough that you want to show it
> around, and you are pumped up!  The only thing that goes through your
> mind is publish, publish, publish!
> 
> So you start writing an exciting blog post full of nice screenshots and
> plans, and you write "you can get MyProg at svn.gnome.org/svn/..."
> 
> Oh, shit.  Giant brick wall.  You cannot create the module by yourself.
> You google for "gnome creating new svn modules" and you get pointed to
> http://developer.gnome.org/tools/svn.html - which leads you to
> http://developer.gnome.org/doc/tutorials/import.html if you want to
> import your code, but THAT WON'T WORK because it still talks about "cvs
> import".

Feel free to fix it and point to NewSVNRepos.

> Okay... so you know that the developer's site is pretty bad and
> outdated, so you go to check the wiki.  Go to live.gnome.org and type
> "svn" in the search box.  Great, the first search hit is
> http://live.gnome.org/NewSVNRepos - which tells you "mail an admin with
> this list of requirements".  Download page?  Project homepage?  Come on,
> this is my first "it barely works" release - I don't have all that set
> up yet!

Ehr? Doesn't it tell you that *if you have a GNOME SVN account*, we only
care about *your GNOME SVN account and your requested module name*?

if it doesn't, just mention this (it is a wiki:). Above is a generic New
SVN repos page, meant for people who want to host their existing SVN
repos on GNOME.

> So you are stuck.  Ask an admin to create a new module?  That will take
> days.  Your energy and happiness go to hell.
> 
> It is very sad that even if you already have an SVN account, you cannot
> create a module by yourself.
> 
> Back when we used CVS, anyone with an account could do "cvs import",
> just as described in the developer's site.  People botched it up and
> imported generated files, etc., but that could be easily fixed.

Only because it was one repos (IIRC).
Suggestions are welcome btw. This without handing people (root) shell
accounts on socket.

> People are using ~foo/git/bar because *it works* without having to ask
> someone else to import your code for you.

If you have shell for another reason. IIRC (no clue really) you could
just as well setup SVN repos on there.. although I don't know for sure
if that Apache stuff is optional or not.
-- 
Regards,
Olav
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Creating new modules (was Re: Git vs SVN (was: Can we improve things?))

[Havoc Pennington]

Hi,

On 9/10/07, Olav Vitters <[EMAIL PROTECTED]> wrote:
> svn-commits-list exists and you can limit the email receive to one or
> more projects (or all).

Right, but like I said I'm not sure it scales anymore; there's too
much stuff in svn to want to get an email per commit. If you limit to
only your projects, then you miss out on learning things by accident,
which is the real value. For example, if you are a library maintainer,
it's very helpful to happen to see commits where people are trying to
use the library. And everyone benefits from noticing new experimental
projects as they appear.

Maybe a daily summary like:
   gnome-panel - whoever (3), someone-else (2)
   ...

where it's all linkified going to the appropriate svn/git web (could
also have mouseover tooltips showing details so you could quickly
scan)

Then the daily summary could be in the planet gnome feed, perhaps.

I don't know, I'm sure there are better solutions, and it's academic
unless someone turns up who decides to try and code something. Just
throwing out ideas.

Havoc
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Creating new modules (was Re: Git vs SVN (was: Can we improve things?))

[Olav Vitters]

On Mon, Sep 10, 2007 at 04:42:03PM -0400, Havoc Pennington wrote:
> Hi,
> 
> On 9/10/07, Federico Mena Quintero <[EMAIL PROTECTED]> wrote:
> > Because it is no longer possible to create new SVN modules easily, as it
> > was when we used CVS.  By "easily" I mean that it you want to create a
> > module, you don't need to ask anyone to do it for you.
> >
> 
> When this first came up on d-d-l I was sort of "not sure this is a big
> deal" but then recently I was thinking about it again and decided it
> did matter.
> 
> Back in the day the cvs-commits-list was part of the community. One of
> the things that frequently happened is that people followed up to
> commit messages to discuss, or noticed a commit and discussed it on
> IRC.

svn-commits-list exists and you can limit the email receive to one or
more projects (or all).

> Anyway, the centralization and common CVS repo was really a big part
> of how the community worked. It let people get credit, it let people
> informally notice where they could help each other, it let everyone
> have a baseline knowledge of what was being worked on.

I think this worked because /cvs/gnome was one big repos right? Now we
create a repos per module. This needs someone with a shell (root) to set
it up. Don't like handing out shell on that machine, but perhaps some
webinterface when possible (after mango).

-- 
Regards,
Olav
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Creating new modules (was Re: Git vs SVN (was: Can we improve things?))

[Havoc Pennington]

Hi,

On 9/10/07, Federico Mena Quintero <[EMAIL PROTECTED]> wrote:
> Because it is no longer possible to create new SVN modules easily, as it
> was when we used CVS.  By "easily" I mean that it you want to create a
> module, you don't need to ask anyone to do it for you.
>

When this first came up on d-d-l I was sort of "not sure this is a big
deal" but then recently I was thinking about it again and decided it
did matter.

Back in the day the cvs-commits-list was part of the community. One of
the things that frequently happened is that people followed up to
commit messages to discuss, or noticed a commit and discussed it on
IRC.

The really important community effect is that you could kind of just
watch everyone working, and if it happened to relate to you or
happened to look interesting, you could pile on. Since commit access
was not per-module but for the whole GNOME project, you probably
already had commit access.

Another social effect is that you knew who was doing work, and if you
did a lot of work you got credit for it without having to
self-promote, since people saw your commits flying by.

Anyway, the centralization and common CVS repo was really a big part
of how the community worked. It let people get credit, it let people
informally notice where they could help each other, it let everyone
have a baseline knowledge of what was being worked on.

Importantly, this happened *even for brand new or experimental
projects*. Those were worth having in the central repo because of the
social and community value of knowing what people were up to and being
able to help them or assign them your respect or whatever accordingly.

Bringing it back to the present, there's stuff on svn.mugshot.org that
really belongs on gnome.org, but it seems it didn't end up there. I
don't think this was a conscious thing, but I think it probably was
due to just enough of a barrier to create a new gnome module. And then
once you start a module in one place, it's a Major Project to move it
(probably not truly a major project, but enough to result in
procrastination).

Anyway. I'm not sure the old cvs-commits-list type approach really
scales to GNOME's current size, but I think something *was* lost.

To give a productive suggestion, I wonder if a nice "code commits
planet" would be a win for GNOME, perhaps somehow mixed in to or in a
sidebar of the current planet. It could track all the repos related to
GNOME and try to display in readable summary form 1) which modules had
commits today and 2) who did the commits. To show who's doing stuff
and what stuff they are doing, at least in terms of which module they
are working on.

Havoc
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Federico Mena Quintero]

On Sat, 2007-09-08 at 10:17 +0200, Olav Vitters wrote:

Hi, Olav,

> You are ignoring the central place. You need somewhere all GNOME devs
> are able to commit. This is what is so wrong about
> www.gnome.org/~foo/git/.

The interesting question is, "why are people doing ~foo/git/blah in the
first place?"

Because it is no longer possible to create new SVN modules easily, as it
was when we used CVS.  By "easily" I mean that it you want to create a
module, you don't need to ask anyone to do it for you.

Think of a gnome.org developer who has just written a new and exciting
program, and wants to make it available.  You are in that beautiful
moment when the program works well enough that you want to show it
around, and you are pumped up!  The only thing that goes through your
mind is publish, publish, publish!

So you start writing an exciting blog post full of nice screenshots and
plans, and you write "you can get MyProg at svn.gnome.org/svn/..."

Oh, shit.  Giant brick wall.  You cannot create the module by yourself.
You google for "gnome creating new svn modules" and you get pointed to
http://developer.gnome.org/tools/svn.html - which leads you to
http://developer.gnome.org/doc/tutorials/import.html if you want to
import your code, but THAT WON'T WORK because it still talks about "cvs
import".

Okay... so you know that the developer's site is pretty bad and
outdated, so you go to check the wiki.  Go to live.gnome.org and type
"svn" in the search box.  Great, the first search hit is
http://live.gnome.org/NewSVNRepos - which tells you "mail an admin with
this list of requirements".  Download page?  Project homepage?  Come on,
this is my first "it barely works" release - I don't have all that set
up yet!

So you are stuck.  Ask an admin to create a new module?  That will take
days.  Your energy and happiness go to hell.

It is very sad that even if you already have an SVN account, you cannot
create a module by yourself.

Back when we used CVS, anyone with an account could do "cvs import",
just as described in the developer's site.  People botched it up and
imported generated files, etc., but that could be easily fixed.

People are using ~foo/git/bar because *it works* without having to ask
someone else to import your code for you.

  Federico

___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Behdad Esfahbod]

On Mon, 2007-09-10 at 00:29 +0200, Christian Rose wrote:
> On 9/9/07, Behdad Esfahbod <[EMAIL PROTECTED]> wrote:
> > On Sun, 2007-09-09 at 18:49 +0200, Christian Rose wrote:
> > > Nothing is ever solved by letting others be
> > > responsible for solving problems that may have been introduced by you.
> > > Or vice versa. That's a basic fact in SCM.
> >
> > But more often than not the build is left broken by a translator.
> 
> But translation commits are also account for a significant share of
> the total number of commits, so any "statistics" are bound to be
> skewed some way if you don't account for the selection.

Fair enough.  What surprises me though is that many translators never
build the software and probably don't test their translation before
committing.  At least that's my impression from watching how broken a
state some leave the module in.

> Still, I supposed this situation had improved since there were
> mandatory precommit checks introduced. Isn't that the case? If not,
> this can probably be improved in a lot of ways.

po/ is hardly a problem these days.  Most common case of broken build in
my experience has been translators moving user docs to gnome-doc-utils
and not correctly updating Makefile.am and configure.ac.  That may just
be a problem in the wiki page about the migration.

> Christian

This really belongs to gnome-i18n.

-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759



___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Lucas Rocha]

Hi all,

Could you please move this discussion to d-d-l and/or
gnome-infrastructure? This mailing list is definitely not the place to
discuss SCM in GNOME.

Thanks,

--lucasr

2007/9/10, Olav Vitters <[EMAIL PROTECTED]>:
> On Mon, Sep 10, 2007 at 08:29:35AM +0300, Kalle Vahlman wrote:
> > 2007/9/8, Olav Vitters <[EMAIL PROTECTED]>:
> > > On Sat, Sep 08, 2007 at 04:47:31PM +0300, Kalle Vahlman wrote:
> > > > And this all is naturally from the developer/maintainer POV, as
> > > > translators and documentors do not benefit from this as much. But as
> > > > the general opinion seems to be, they shouldn't be forced to use SCM:s
> > > > directly anyway.
> > >
> > > That is a theoretical discussion. Ideally GNOME has a D-SCM now and all
> > > translators use a websystem that automatically translators. It doesn't 
> > > exist.
> >
> > Of course it is theoretical since there's no hope (nor sense) in
> > switching over to anything before there are tools. As is pointed out,
> > it would make things worse for non-developres.
>
> D-SCM systems exist. Such a translator tool does not. Especially as
> someone has to write that tool, I do not like discussions that involve a
> tool 'someone will write' (well, unless one of the damned-lies people
> shows a clear proposal; including authentication bits).
>
> > But that doesn't mean the discussion needs to be punted indefinetly,
> > and statements like "I don't want to learn a new SCM" are really not
> > contributing to a discussion of the benefits a new tool would give to
> > developers. At least I thought we were discussing exactly that.
>
> I disagree. It translates to easy of use. Why should I have to care how
> a SCM works? A tool should either warn me strongly before doing
> something wrong, or prevent it outright. It should have a --help that is
> understandable. The man pages should have the most common usages, etc.
>
> I'm all for some D-SCM tool that provides benefits to people who
> understand (D-)SCM in&out, but I need to use it as well. Perhaps git now
> is good enough, no idea. But just discussing benefits of some tool
> without discussing ease of use is ignoring part of the users.
>
> > > Although there is now some progress towards D-SCM, I don't see
> > > such a websystem happening. Also am not sure if a websystem is the most
> > > appropriate way.
> >
> > I'd much rather see something like SCM support for gtranslate which
> > would give a comfortable tool to translate and send changes to the
> > server.
>
>
>
> --
> Regards,
> Olav
> ___
> foundation-list mailing list
> foundation-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/foundation-list
>
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Olav Vitters]

On Mon, Sep 10, 2007 at 08:29:35AM +0300, Kalle Vahlman wrote:
> 2007/9/8, Olav Vitters <[EMAIL PROTECTED]>:
> > On Sat, Sep 08, 2007 at 04:47:31PM +0300, Kalle Vahlman wrote:
> > > And this all is naturally from the developer/maintainer POV, as
> > > translators and documentors do not benefit from this as much. But as
> > > the general opinion seems to be, they shouldn't be forced to use SCM:s
> > > directly anyway.
> >
> > That is a theoretical discussion. Ideally GNOME has a D-SCM now and all
> > translators use a websystem that automatically translators. It doesn't 
> > exist.
> 
> Of course it is theoretical since there's no hope (nor sense) in
> switching over to anything before there are tools. As is pointed out,
> it would make things worse for non-developres.

D-SCM systems exist. Such a translator tool does not. Especially as
someone has to write that tool, I do not like discussions that involve a
tool 'someone will write' (well, unless one of the damned-lies people
shows a clear proposal; including authentication bits).

> But that doesn't mean the discussion needs to be punted indefinetly,
> and statements like "I don't want to learn a new SCM" are really not
> contributing to a discussion of the benefits a new tool would give to
> developers. At least I thought we were discussing exactly that.

I disagree. It translates to easy of use. Why should I have to care how
a SCM works? A tool should either warn me strongly before doing
something wrong, or prevent it outright. It should have a --help that is
understandable. The man pages should have the most common usages, etc.

I'm all for some D-SCM tool that provides benefits to people who
understand (D-)SCM in&out, but I need to use it as well. Perhaps git now
is good enough, no idea. But just discussing benefits of some tool
without discussing ease of use is ignoring part of the users.

> > Although there is now some progress towards D-SCM, I don't see
> > such a websystem happening. Also am not sure if a websystem is the most
> > appropriate way.
> 
> I'd much rather see something like SCM support for gtranslate which
> would give a comfortable tool to translate and send changes to the
> server.



-- 
Regards,
Olav
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Kalle Vahlman]

2007/9/8, Olav Vitters <[EMAIL PROTECTED]>:
> On Sat, Sep 08, 2007 at 04:47:31PM +0300, Kalle Vahlman wrote:
> > 2007/9/8, Olav Vitters <[EMAIL PROTECTED]>:
> > > On Sat, Sep 08, 2007 at 05:56:38AM -0400, Kevin Kubasik wrote:
> > > Let's summarize it as: I don't know any D-SCM :-) (only investigate by
> > > checking out docs)
> > > (but I am also not interested in learning a SCM)
> >
> > Hopefully that doesn't translate "I don't know and I don't care"...
>
> It translates to: I really care about not needing to learn an SCM.

Ok, so discussion on the benefits of Git (or others) over SVN seem a
bit pointless from this standpoint.

> Take for example the output of 'git'
>   push  Update remote refs along with associated objects
>
> That to me is a 'wtf?' (1.5.2).

At least it has text, unlike SVN ;)

[snip]
> I didn't have to learn SVN.

You must be a quick learner then. I remember having to refer to the
SVN book loads of times before I could use SVN for merging and so on.

> > And this all is naturally from the developer/maintainer POV, as
> > translators and documentors do not benefit from this as much. But as
> > the general opinion seems to be, they shouldn't be forced to use SCM:s
> > directly anyway.
>
> That is a theoretical discussion. Ideally GNOME has a D-SCM now and all
> translators use a websystem that automatically translators. It doesn't exist.

Of course it is theoretical since there's no hope (nor sense) in
switching over to anything before there are tools. As is pointed out,
it would make things worse for non-developres.

But that doesn't mean the discussion needs to be punted indefinetly,
and statements like "I don't want to learn a new SCM" are really not
contributing to a discussion of the benefits a new tool would give to
developers. At least I thought we were discussing exactly that.

> Although there is now some progress towards D-SCM, I don't see
> such a websystem happening. Also am not sure if a websystem is the most
> appropriate way.

I'd much rather see something like SCM support for gtranslate which
would give a comfortable tool to translate and send changes to the
server.

-- 
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Christian Rose]

On 9/9/07, Behdad Esfahbod <[EMAIL PROTECTED]> wrote:
> On Sun, 2007-09-09 at 18:49 +0200, Christian Rose wrote:
> > Nothing is ever solved by letting others be
> > responsible for solving problems that may have been introduced by you.
> > Or vice versa. That's a basic fact in SCM.
>
> But more often than not the build is left broken by a translator.

But translation commits are also account for a significant share of
the total number of commits, so any "statistics" are bound to be
skewed some way if you don't account for the selection.

Still, I supposed this situation had improved since there were
mandatory precommit checks introduced. Isn't that the case? If not,
this can probably be improved in a lot of ways.


Christian
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Behdad Esfahbod]

On Sun, 2007-09-09 at 18:49 +0200, Christian Rose wrote:
> Nothing is ever solved by letting others be
> responsible for solving problems that may have been introduced by you.
> Or vice versa. That's a basic fact in SCM. 

But more often than not the build is left broken by a translator.

-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759



___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Christian Rose]

On 9/9/07, Steve Frécinaux <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-09-08 at 12:48 -0400, Behdad Esfahbod wrote:
> >   - Move translations out of modules into a new module dedicated to
> > translations of all GNOME modules.  Fixes many build-broken issues but
> > has many more issues.
>
> That's how KDE guys do, I think. IMHO it has the following advantages:
>
> - what takes the longest while building a new checkout are translations
>   of strings and help files.
> - translator work doesn't get in the way of developers, and the other
>   way.

It also has many serious problems. Problems with synching, lack of
context, updated translations not always being incorporated into
releases, etc. There is an advantage with having everything in one
place, but apart from that, everything else seems to be drawbacks
arising from introducing yet another artificial layer.


> - most developers don't understand much at how the po/ and help/
>   directories work, which makes those broken more often than never.

In my book, that's an advantage of the current system -- most
maintainers know the basics of the po and help directories. And you
need to know the basics about building your software. Not much, but at
least the basics. If you don't know how to fix your app, who should?
Encouraging the notation that some parts of your application are the
responsibility of "others" in an isolated space and you don't need at
all care about those parts, probably isn't a good way to get good
quality in the end. Nothing is ever solved by letting others be
responsible for solving problems that may have been introduced by you.
Or vice versa. That's a basic fact in SCM.

Furthermore, in GNOME, we have many translators that started out with
just translating, but continued with fixing bugs, and some are full
time coders now. We should be proud of this integration in the
community.
Getting the impression that some are still advocating to the effect of
"coders are born coders and translators are born translators, and
let's get an isolated sand box for the translators to play in" just
makes me sad.


Christian
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Behdad Esfahbod]

On Sun, 2007-09-09 at 13:37 +0200, Steve Frécinaux wrote:
> 
> 
> On Sat, 2007-09-08 at 09:41 -0700, Sanford Armstrong wrote:
> 
> > I simply meant that less people are familiar with D-SCM tools and that
> > they are somewhat harder for a newbie to learn than C-SCM tools. 


Not necessarily.  Try tagging in svn.  It's so hard I had to write a
couple scripts:

$ cat gnome-tag-release 
#!/bin/bash
if test x$# != x3; then
echo gnome-tag module tag release
exit
fi
svn copy svn+ssh://svn.gnome.org/svn/$1/trunk 
svn+ssh://svn.gnome.org/svn/$1/tags/$2 -m "Tagged for release $3."


Yeah, it's conceptually easy: "svn copy from to", but makes absolutely
no sense even compared to cvs.

-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759



___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Steve Frécinaux]

On Sun, 2007-09-09 at 13:24 +0200, Steve Frécinaux wrote:
> Then you just do not create a new branch, commit when you're done on the
> master branch, and push the patch once it is ready, or attach it to a
> bugzilla bug using git-send-bugzilla [1]. Note that git allows you to
> "amend" a commit, ie fixing it if you notice it is broken in some way,
> as long as you don't have pushed it (very useful).

[1] http://tw.apinc.org/weblog/2007/01/16#using-git-with-bugzilla

___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Steve Frécinaux]

On Sat, 2007-09-08 at 09:41 -0700, Sanford Armstrong wrote:

> I simply meant that less people are familiar with D-SCM tools and that
> they are somewhat harder for a newbie to learn than C-SCM tools.

You're mistaken. Actually, it's not harder to learn a DSCM than a
regular centralised one. What makes it harder to learn for *regular* SCM
users is that a few concepts and way-to-do-things are different.

I explained how to use git to a friend of mine (because he has no server
available, and it was easier for him to backup everything since he only
has to burn the checkout directory with the .git directory in it). He
was able to get it working fastly enough. Faster than I was, in fact,
due to my inherited CVS and SVN habits.


___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Steve Frécinaux]

On Sat, 2007-09-08 at 12:48 -0400, Behdad Esfahbod wrote:

>   - Move translations out of modules into a new module dedicated to
> translations of all GNOME modules.  Fixes many build-broken issues but
> has many more issues.

That's how KDE guys do, I think. IMHO it has the following advantages:

- what takes the longest while building a new checkout are translations 
  of strings and help files.
- translator work doesn't get in the way of developers, and the other 
  way.
- most developers don't understand much at how the po/ and help/
  directories work, which makes those broken more often than never.

___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Steve Frécinaux]

On Sat, 2007-09-08 at 22:23 +0200, Olav Vitters wrote:
> On Sat, Sep 08, 2007 at 04:47:31PM +0300, Kalle Vahlman wrote:
> > 2007/9/8, Olav Vitters <[EMAIL PROTECTED]>:
> > > On Sat, Sep 08, 2007 at 05:56:38AM -0400, Kevin Kubasik wrote:
> > > Let's summarize it as: I don't know any D-SCM :-) (only investigate by
> > > checking out docs)
> > > (but I am also not interested in learning a SCM)
> > 
> > Hopefully that doesn't translate "I don't know and I don't care"...
> 
> It translates to: I really care about not needing to learn an SCM.

You can use git as you use svn currently.
Just remember about git pull/commit/push and you're done.

> Take for example the output of 'git'
>   push  Update remote refs along with associated objects

This is just some terminology. A ref (reference) is a generic name for
tags and branches. 

> > > For me, I consider the "you don't change directories for each branch you
> > > make" a drawback. I find directories as branches easier to understand (I
> > > hated this in CVS).
> > 
> > There's some tools to visualize the branch history in git, which
> > includes more information than just "this is a branch".

Such a tool is gitk which is really worth looking.

Note that I was also reluctant to use more than one branch for a
checkout directory, because I found it confusing and I was afraid about
build issues. But in practice everything works fine, and stuff like
ccache just makes it better. You are not likely to change many files by
checkouting another branch in typical usage (ie, closely related
patches), and nothing retains you from having a directory for each major
branch (say, gnome-2-16 and gnome-2-18).

Also, using several branches in a single directory allows convenient
things like saying 'oh, what I just coded doesn't belong to that current
patch, let's put it in another branch!'. Once you've created a branch
and commited your patch, you can rebase it where you want in the tree by
checkouting the relevant commit (for instance, the HEAD branch of the
remote repository) and applying the last commit on top of it (hopes it's
not too cryptic). Lastly it doesn't need you to have several copies of
the history, thus lowering disk usage.

But as I said, nothing forces you to have more than one branch per
checkout directory, and multiple directories, as you currently do with
SVN.

> > > > mkdir projdir && cd projdir
> > > > git clone ssh://[EMAIL PROTECTED]/git/coolproject/kkubasik
> > > > git branch newcoolfeature
> > > > git checkout newcoolfeature
> > >
> > > I don't like this checkout step.
> > 
> > You can merge it with the branch command if you like:
> > 
> >   git checkout -b newcoolfeature
> 
> It is not about one command. One dir per branch is perfectly
> understandable for me. 

Then you just do not create a new branch, commit when you're done on the
master branch, and push the patch once it is ready, or attach it to a
bugzilla bug using git-send-bugzilla [1]. Note that git allows you to
"amend" a commit, ie fixing it if you notice it is broken in some way,
as long as you don't have pushed it (very useful).

Also, something I do very frequently, is to have a branch for the change
where I commit often, and then "squash" it onto one single patch on the
master branch (equivalent to svn trunk) using git-merge --squash. This
allows you to have an history of your patch life, thus spotting
regressions easily and being able to get back to a previous version of
the patch. This is another advantage of being able to have several
branches in a single commit directory, as I'm pretty sure you already
ran into that issue using SVN...

> Equivalent of git- is not svn, it is svn-. I mean that
> there is too much stuff that gets in the way.

Equivalent of svn  is git . The 'git' command is meant to be
the actual frontend (while git-* are mostly lower level commands, which
allow useful things like making your own scripts to do several things
automatically, as client-side hooks and such).

Well, git  presents 140 commands here, but it's a bug in the bash
completion script, since git --help only gives 30 commands. svn --help
gives more commands than that.

> > And furthermore, looking at git commands is absolutely the worst way
> > to start learning git. Specially when coming from SVN, git commands as
> > they are will make no sense at all. But, when you read up and look at
> > few pretty pictures about how git works (like in
> > http://eagain.net/articles/git-for-computer-scientists/ ), they start
> > to make sense and you'll see how they turn SCM from just storing
> > snapshots of file states to actual tool for managing a project and
> > it's changes.
> 
> I didn't have to learn SVN.

You don't have to learn git either, it mostly depends on what you're
going to do with it. On my own, I began with the usual combo
clone/pull/commit/push, and only learnt about branches and stuff later.
But it's sure that understanding how things work under the hood helps,
as for any other (D)SCM. Yeah

Re: Git vs SVN (was: Can we improve things?)

[Jeff Waugh]

> I simply meant that less people are familiar with D-SCM tools and that
> they are somewhat harder for a newbie to learn than C-SCM tools.

This is an unfortunate cultural relic created by arch/tla, and hilariously
promulgated by git. Sure, fewer people are familiar with them, but the good
ones are not harder to learn. In fact, because full source code management
functionality is available to you without having prior permission from the
developers (an account), you can learn the basics (functionality shared by
distributed and centralised systems) way faster.

(The only difficult/additional thing to learn in the current environment is
distributed best practices, and that is only an issue if you're actually
using the distributed functionality; just because the tool does it, doesn't
mean you have to!)

- Jeff

-- 
linux.conf.au 2008: Melbourne, Australiahttp://lca2008.linux.org.au/
 
 "No shit, [EMAIL PROTECTED]" - Mr. Bad
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Olav Vitters]

On Sat, Sep 08, 2007 at 04:47:31PM +0300, Kalle Vahlman wrote:
> 2007/9/8, Olav Vitters <[EMAIL PROTECTED]>:
> > On Sat, Sep 08, 2007 at 05:56:38AM -0400, Kevin Kubasik wrote:
> > Let's summarize it as: I don't know any D-SCM :-) (only investigate by
> > checking out docs)
> > (but I am also not interested in learning a SCM)
> 
> Hopefully that doesn't translate "I don't know and I don't care"...

It translates to: I really care about not needing to learn an SCM.

Take for example the output of 'git'
  push  Update remote refs along with associated objects

That to me is a 'wtf?' (1.5.2).

> > For me, I consider the "you don't change directories for each branch you
> > make" a drawback. I find directories as branches easier to understand (I
> > hated this in CVS).
> 
> There's some tools to visualize the branch history in git, which
> includes more information than just "this is a branch".
> 
> > > mkdir projdir && cd projdir
> > > git clone ssh://[EMAIL PROTECTED]/git/coolproject/kkubasik
> > > git branch newcoolfeature
> > > git checkout newcoolfeature
> >
> > I don't like this checkout step.
> 
> You can merge it with the branch command if you like:
> 
>   git checkout -b newcoolfeature

It is not about one command. One dir per branch is perfectly
understandable for me. 

> > > 
> > > git commit -a
> >
> > Is the confusing way removed? If I do git- I see 'Display all 144
> > possibilities'. Why so many?
> 
> Because that's how git is structured. It's a collection of little
> tools to do specific tasks. You'll likely use 4-5 of them in normal
> developer tasks. Also, invoking 'git' gives you the most common ones.
> If you do svn there's only one useful command out of 9 (on my
> machine) and it doesn't tell what it does either just by looking at
> the name. Does that really mean anything?

Equivalent of git- is not svn, it is svn-. I mean that
there is too much stuff that gets in the way.

> And furthermore, looking at git commands is absolutely the worst way
> to start learning git. Specially when coming from SVN, git commands as
> they are will make no sense at all. But, when you read up and look at
> few pretty pictures about how git works (like in
> http://eagain.net/articles/git-for-computer-scientists/ ), they start
> to make sense and you'll see how they turn SCM from just storing
> snapshots of file states to actual tool for managing a project and
> it's changes.

I didn't have to learn SVN.

> And this all is naturally from the developer/maintainer POV, as
> translators and documentors do not benefit from this as much. But as
> the general opinion seems to be, they shouldn't be forced to use SCM:s
> directly anyway.

That is a theoretical discussion. Ideally GNOME has a D-SCM now and all
translators use a websystem that automatically translators. It doesn't
exist. Although there is now some progress towards D-SCM, I don't see
such a websystem happening. Also am not sure if a websystem is the most
appropriate way.

> > Easy stuff should be easy, hard stuff
> > should be harder (otherwise the easy stuff is confusing). I never liked
> > CVS, but I like SVN.. easy to understand.
> 
> There was great commotion about people not wanting to switch to svn
> because they had to learn new SCM. I bet nobody today wants to go back
> to CVS though, and it is bound to be the same for the next step too...

Git is not SVN. On the Bugzilla account, I started out with:
  alias cvs='svn'
because I wanted to prevent someone typing in the wrong commands. It is
pretty similar (CVS/SVN commands). There is no need for me to learn a
D-SCM. I'm perfectly happy if git commit would first try to commit
remotely, and if that fails, locally. That is the kind of D-SCM I'd
like (probably pretty unique in that).

> > Anyway, I think you forgot the 'push'.
> >
> > > Now you have 2 branches (the original, and newcoolfeature) where new
> > > cool feature has your changes.
> >
> > Is it easy enough if you want to avoid branches? I usually work on
> > trunk, nothing else (I do understand people want better merging than
> > available in SVN).
> 
> Even more pleasant as you "own" the cloned repo and nothing happens on
> the central server until you really want it to.
> 
> But I guess that's for the "newbie-committee" to decide if there ever
> will be one...

-- 
Regards,
Olav
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Behdad Esfahbod]

On Fri, 2007-09-07 at 22:35 -0400, Kevin Kubasik wrote:
[...]
> 3) git-svn is an acceptable and stable program, while we should not
> base a system off of it, asking that developers do use it is not out
> of the question.

This is not true.  I'm a git lover, but tried git-svn and couldn't make
it work for me.  Doesn't work with glib because of the svn:external
directory and even with pango I gave up as switching between branches
and even committing+pushing is not as easy as I hoped.

[...]
> 2) Even with the addition of git.gnome.org, at this point, Subversion
> remains the final and master copy of all Gnome source. Individual
> projects are free to branch and merge and frolic as they please, but
> it is imperative that the Subversion trunk remain the tip of active
> development. Be that through the forwarding of patches through git
> systems, or as it always has taken place. However, new projects are
> asked to use git, and simply treat Subversion as the master branch,
> where all changes are eventually pushed at release time.

This will just waste more maintainer time.


> 3) At this point, if all has gone well, we allow evangelist project
> maintainers to move to git exclusively if they so desire, this will
> help us asses the migration tools and times for a realistic assessment
> of the next step.

Fair enough.

[...]
> * Doesn't address the translators learning new software component. -
> Yes, it does, the beauty of forcing the SVN repos to stay active,
> while using them with git is that as long as the git->svn action only
> involves one git branch and one subversion branch, things are neat and
> cheery. Now using git to manage branches in subversion is just plain
> stupid, but translators could continue to work in the old system as
> long as the developers remember to occasionally fetch any changes.
> This reflects a serious change in mentality that DRCS' can enable.
> Merging is not the devil, its cheap, easy, reliable, clean, and part
> of distributed development.

If translators are getting in the way of hackers using their best tools,
we should find how to fix it.  I see two ways:

  - Provide online tools for translation such that those who don't want
to deal with git/svn/... can use it for all their needs.

  - Move translations out of modules into a new module dedicated to
translations of all GNOME modules.  Fixes many build-broken issues but
has many more issues.

-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759



___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Sanford Armstrong]

On 9/8/07, Jeff Waugh <[EMAIL PROTECTED]> wrote:
> 
>
> > My personal opinion is that in the short term, using a D-SCM actually
> > raises the barrier for entry for *new* developers.
>
> Why so? Being able to branch and start working -- including making newbie
> mistakes -- completely safely in revision control, and being able to expose
> that to the broader project is an *awesome* way to lower the barrier to
> entry for new developers. You can be doing significantly more useful (and
> just plain "more") work, faster.

I simply meant that less people are familiar with D-SCM tools and that
they are somewhat harder for a newbie to learn than C-SCM tools.
There is also the laziness factor, as Alex mentioned recently [1].
People who just figured out SVN may be discouraged if they have to
learn a D-SCM to get started in GNOME development.  I'm not disputing
that a new developer can do a lot more with D-SCM when they're first
starting off.  But right now that's a somewhat steeper learning curve.

Cheers,
Sandy

[1] http://www.beatniksoftware.com/blog/?p=74
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Jeff Waugh]

> My personal opinion is that in the short term, using a D-SCM actually
> raises the barrier for entry for *new* developers.

Why so? Being able to branch and start working -- including making newbie
mistakes -- completely safely in revision control, and being able to expose
that to the broader project is an *awesome* way to lower the barrier to
entry for new developers. You can be doing significantly more useful (and
just plain "more") work, faster.

- Jeff

-- 
GNOME Boston Summit 2007http://live.gnome.org/Boston2007
 
  Push the envelope, or push the daisies.
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Kalle Vahlman]

2007/9/8, Olav Vitters <[EMAIL PROTECTED]>:
> On Sat, Sep 08, 2007 at 05:56:38AM -0400, Kevin Kubasik wrote:
> Let's summarize it as: I don't know any D-SCM :-) (only investigate by
> checking out docs)
> (but I am also not interested in learning a SCM)

Hopefully that doesn't translate "I don't know and I don't care"...

> For me, I consider the "you don't change directories for each branch you
> make" a drawback. I find directories as branches easier to understand (I
> hated this in CVS).

There's some tools to visualize the branch history in git, which
includes more information than just "this is a branch".

> > mkdir projdir && cd projdir
> > git clone ssh://[EMAIL PROTECTED]/git/coolproject/kkubasik
> > git branch newcoolfeature
> > git checkout newcoolfeature
>
> I don't like this checkout step.

You can merge it with the branch command if you like:

  git checkout -b newcoolfeature

> > 
> > git commit -a
>
> Is the confusing way removed? If I do git- I see 'Display all 144
> possibilities'. Why so many?

Because that's how git is structured. It's a collection of little
tools to do specific tasks. You'll likely use 4-5 of them in normal
developer tasks. Also, invoking 'git' gives you the most common ones.
If you do svn there's only one useful command out of 9 (on my
machine) and it doesn't tell what it does either just by looking at
the name. Does that really mean anything?

And furthermore, looking at git commands is absolutely the worst way
to start learning git. Specially when coming from SVN, git commands as
they are will make no sense at all. But, when you read up and look at
few pretty pictures about how git works (like in
http://eagain.net/articles/git-for-computer-scientists/ ), they start
to make sense and you'll see how they turn SCM from just storing
snapshots of file states to actual tool for managing a project and
it's changes.

And this all is naturally from the developer/maintainer POV, as
translators and documentors do not benefit from this as much. But as
the general opinion seems to be, they shouldn't be forced to use SCM:s
directly anyway.

> Easy stuff should be easy, hard stuff
> should be harder (otherwise the easy stuff is confusing). I never liked
> CVS, but I like SVN.. easy to understand.

There was great commotion about people not wanting to switch to svn
because they had to learn new SCM. I bet nobody today wants to go back
to CVS though, and it is bound to be the same for the next step too...

> Anyway, I think you forgot the 'push'.
>
> > Now you have 2 branches (the original, and newcoolfeature) where new
> > cool feature has your changes.
>
> Is it easy enough if you want to avoid branches? I usually work on
> trunk, nothing else (I do understand people want better merging than
> available in SVN).

Even more pleasant as you "own" the cloned repo and nothing happens on
the central server until you really want it to.

But I guess that's for the "newbie-committee" to decide if there ever
will be one...

-- 
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Sanford Armstrong]

On 9/8/07, Olav Vitters <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 08, 2007 at 03:23:31PM +0300, Zeeshan Ali wrote:
> > Hi!
> >Was hard to sleep last night after i sent my last message so i must
> > clarify something before i attempt to answer anyone's reply:
> >
> > >   You need to look at it a bit objectively. Linus says "you are stupid
> > > and ugly" because you truly are stupid if you prefer to use SVN or any
> > > centralized SCM and he clearly points out most of the reason why this
> > > it the honest truth.
> >
> >   *I* am not calling anyone stupid, it was Linus and I only quoted.
> > Still i am sorry i did that, guess i just got taken away..
>
> Oh, sorry for misunderstanding you. From the way you replied, I thought
> it was your opinion too.

If you watch Linus' presentation, it's kind of a running joke that
anyone who disagrees with him must be "stupid and ugly".

That being said, he doesn't spend too much time backing up his
conclusions about SVN.  They basically amount to:

1) Linus hated CVS (and most people in the audience agree).
2) SVN is similar in usage to CVS.
3) Therefore, SVN cannot possibly be a good tool.

So I wouldn't say that the presentation does a very good job of
objectively proving the greatness of D-SCM.  However, it does give
great insight into git itself, the kernel development style, and
Linus' personal usage of the tool.

My personal opinion is that in the short term, using a D-SCM actually
raises the barrier for entry for *new* developers.  The biggest
winners of an instant conversion to D-SCM would be regular
contributors without SVN accounts (followed next by maintainers and
others who long for better merging).  In the long term, as more people
are used to the D-SCM tools (with their inevitably more complicated
UIs), and as more distros ship them by default, and as they continue
to improve, the positive impact will be more widespread.

I know their are a few random blog posts floating around, but I'd like
to see something on l.g.o that documents the suggested workflow for
git-svn/bzr-svn/hg-svn/etc.  Is it really a passable solution to all
this?  Does it help regular contributors without SVN accounts in a
concrete way?

Sandy
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Kalle Vahlman]

2007/9/8, Olav Vitters <[EMAIL PROTECTED]>:
> On Sat, Sep 08, 2007 at 12:57:26PM +0300, Kalle Vahlman wrote:
> > Yes, I guess Zeeshan was pointing out that with Git you can clean the
> > typo up *without* having the "oops, typo" as a separate commit, thus
> > making it possible to for example autogenerate the Changelog from git
> > log and not having to clean hundreds of irrelevant messages from it.
>
> How? Can you remove a commit from a central repos?

At least in Git the "central repo" is purely a policy question, so
yes, you can remove it from there too. Or rather edit the commit that
had the typo in it.

But the real benefit is that you can commit pretty freely on-the-go,
and then just create the changeset you want others to see. This alone
will reduce the amount of "oops"-commits. This of course is available
through git-svn already.

> You can actually edit commit message in SVN as well, but I don't like
> that (touching history)..

Even if it's history nobody will ever care about or even want to see?

-- 
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Olav Vitters]

On Sat, Sep 08, 2007 at 03:23:31PM +0300, Zeeshan Ali wrote:
> Hi!
>Was hard to sleep last night after i sent my last message so i must
> clarify something before i attempt to answer anyone's reply:
> 
> >   You need to look at it a bit objectively. Linus says "you are stupid
> > and ugly" because you truly are stupid if you prefer to use SVN or any
> > centralized SCM and he clearly points out most of the reason why this
> > it the honest truth.
> 
>   *I* am not calling anyone stupid, it was Linus and I only quoted.
> Still i am sorry i did that, guess i just got taken away..

Oh, sorry for misunderstanding you. From the way you replied, I thought
it was your opinion too.

-- 
Regards,
Olav
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Zeeshan Ali]

Hi!
   Was hard to sleep last night after i sent my last message so i must
clarify something before i attempt to answer anyone's reply:

>   You need to look at it a bit objectively. Linus says "you are stupid
> and ugly" because you truly are stupid if you prefer to use SVN or any
> centralized SCM and he clearly points out most of the reason why this
> it the honest truth.

  *I* am not calling anyone stupid, it was Linus and I only quoted.
Still i am sorry i did that, guess i just got taken away..

-- 
Regards,

Zeeshan Ali
FSF member#5124
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Olav Vitters]

On Sat, Sep 08, 2007 at 12:57:26PM +0300, Kalle Vahlman wrote:
> 2007/9/8, Olav Vitters <[EMAIL PROTECTED]>:
> > On Sat, Sep 08, 2007 at 02:03:20AM +0300, Zeeshan Ali wrote:
> > >I searched the archive and topics of the mails i found, didn't seem
> > > relevant so it would be nice if you either provide me a link to the
> > > thread or summarize the conclusion. We are using SVN so ChangeLog
> > > requirement obviously makes sense but I can't imagine it making any
> > > sense at all in D-SCMs especially git since i can always get the
> > > changelog using `git log`.
> >
> > You can always use 'svn log' as well. The main point is that 'oops, made
> > a typo' will appear in 'svn log', not in ChangeLog.
> 
> Yes, I guess Zeeshan was pointing out that with Git you can clean the
> typo up *without* having the "oops, typo" as a separate commit, thus
> making it possible to for example autogenerate the Changelog from git
> log and not having to clean hundreds of irrelevant messages from it.

How? Can you remove a commit from a central repos?

You can actually edit commit message in SVN as well, but I don't like
that (touching history).. it is not enabled on svn.gnome.org. Don't
remember if you can remove the commit (think not).

Maybe we should just have something like "SILENT: "

> (not that this either would solve the original issue)

-- 
Regards,
Olav
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Olav Vitters]

On Sat, Sep 08, 2007 at 05:56:38AM -0400, Kevin Kubasik wrote:
> I should start by saying, I used the word 'git' here to really mean
> most any dscm. I personally use Mercurial for my school stuff, (small

Ok. I think if we choose something, it should something we want to
switch to. E.g., if we try out Git, it means we'll move to Git (barring
nasty problems). This is what I did not like about your previous mail
(too much Git).

> 3-4 person development teams on shorter term projects) and I use bzr
> with Launchpad daily. I would recommend against choosing bzr simply
> because the performance issue is so pervasive, otherwise, any DSCM
> really would fit the order. Although, in practice the only realistic
> choices are probably bzr, hg, git, or mtn.

What is the speed of bzr v0.90 like compared to SVN? SVN is said to be
slow as well. Is Bzr noticeably slower?

All the popular (in usage.. except CVS) (D-)SCM evolve. Before GNOME is
ready to switch a lot of development will have happened in the various
tools. So if Git had Windows as a priority, I'd expect Windows to be
solved soon enough.
Another point for SVN is that everything seems to integrate with it.

> On 9/8/07, Olav Vitters <[EMAIL PROTECTED]> wrote:
> > On Fri, Sep 07, 2007 at 10:35:55PM -0400, Kevin Kubasik wrote:
> > > While I don't wish to sound trite, I do think almost everyone here
> > > knows what everyone else is going to say, and maybe trying to
> > > headstart the discussion is a bad move, and presumptuous, but allow me
> > > to throw out an idea.
> > >
> > > I think we are more or less in agreement that:
> > > 1) git would lower the barrier of entry for new developers,
> > > 2) git offers some significant benefits  when it comes to sharing and
> > > tracking patches, specifically in the realm of testing and/or release
> > > branching.
> >
> > And so does most of every D-SCM out there. I really don't like Git
> > (windows not being a priority, too complicated, SHA1 collision, etc).
> I don't want to sounds preachy and contradictory, but before I wrote
> this I agreed very strongly with you. I have experimented with git on
> several occasions but before the latest release never considered it a
> real possibility because it was so overly complicated. The new
> interface is almost the exact same as every other distributed system,
> the only real difference is that you don't change directories for each
> branch you make. The 5 seconds primer for working from a centralized
> system would be:

Let's summarize it as: I don't know any D-SCM :-) (only investigate by
checking out docs)
(but I am also not interested in learning a SCM)

For me, I consider the "you don't change directories for each branch you
make" a drawback. I find directories as branches easier to understand (I
hated this in CVS).

> mkdir projdir && cd projdir
> git clone ssh://[EMAIL PROTECTED]/git/coolproject/kkubasik
> git branch newcoolfeature
> git checkout newcoolfeature

I don't like this checkout step.

> 
> git commit -a

Is the confusing way removed? If I do git- I see 'Display all 144
possibilities'. Why so many? Easy stuff should be easy, hard stuff
should be harder (otherwise the easy stuff is confusing). I never liked
CVS, but I like SVN.. easy to understand.

Anyway, I think you forgot the 'push'.

> Now you have 2 branches (the original, and newcoolfeature) where new
> cool feature has your changes.

Is it easy enough if you want to avoid branches? I usually work on
trunk, nothing else (I do understand people want better merging than
available in SVN).

> > > 4) A complete migration at this point is foolhardy, we just did a big
> > > one, the sysadmin team is strained, and simply put, Subversion isn't
> > > all that bad.
> > > 5) Asking that translators and documenters learn a new (and radially
> > > different) version control system is unreasonable. While the concepts
> > > behind git may work and make great sense for a Computer Science major,
> > > we would probably lose not only a lot of productive translator time
> > > (which is unbelievably valuable as it is), but we might even lose
> > > translators to the frustration of an overly complicated system.
> >
> > You have haven't investigated if Git is ok in the end for them in this
> > proposal.
> >
> > E.g. can git checkout just one file, or just one directory? And be able
> > to commit a new version back (I don't mean a 'svn cat' equivalent). Is
> > there a GUI? Is it available on most distros (a version that will be
> > ok), in the distro versions most translators/documenters have installed?
> > etc.
> 
> This was discussed over at Debian,
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg11777.html

I'll check it out later. Probably translators need to
investigate/comment anyway. D-SCM should hopefully be better for
translators though (currently only the coordinator of a language has SVN
and has to commit the patches from other translators.. D-SCM should
help.. if all translators could use it without needing f

Re: Git vs SVN (was: Can we improve things?)

[Kalle Vahlman]

2007/9/8, Olav Vitters <[EMAIL PROTECTED]>:
> On Sat, Sep 08, 2007 at 02:03:20AM +0300, Zeeshan Ali wrote:
> >I searched the archive and topics of the mails i found, didn't seem
> > relevant so it would be nice if you either provide me a link to the
> > thread or summarize the conclusion. We are using SVN so ChangeLog
> > requirement obviously makes sense but I can't imagine it making any
> > sense at all in D-SCMs especially git since i can always get the
> > changelog using `git log`.
>
> You can always use 'svn log' as well. The main point is that 'oops, made
> a typo' will appear in 'svn log', not in ChangeLog.

Yes, I guess Zeeshan was pointing out that with Git you can clean the
typo up *without* having the "oops, typo" as a separate commit, thus
making it possible to for example autogenerate the Changelog from git
log and not having to clean hundreds of irrelevant messages from it.

(not that this either would solve the original issue)

-- 
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Kevin Kubasik]

I should start by saying, I used the word 'git' here to really mean
most any dscm. I personally use Mercurial for my school stuff, (small
3-4 person development teams on shorter term projects) and I use bzr
with Launchpad daily. I would recommend against choosing bzr simply
because the performance issue is so pervasive, otherwise, any DSCM
really would fit the order. Although, in practice the only realistic
choices are probably bzr, hg, git, or mtn.

On 9/8/07, Olav Vitters <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 07, 2007 at 10:35:55PM -0400, Kevin Kubasik wrote:
> > While I don't wish to sound trite, I do think almost everyone here
> > knows what everyone else is going to say, and maybe trying to
> > headstart the discussion is a bad move, and presumptuous, but allow me
> > to throw out an idea.
> >
> > I think we are more or less in agreement that:
> > 1) git would lower the barrier of entry for new developers,
> > 2) git offers some significant benefits  when it comes to sharing and
> > tracking patches, specifically in the realm of testing and/or release
> > branching.
>
> And so does most of every D-SCM out there. I really don't like Git
> (windows not being a priority, too complicated, SHA1 collision, etc).
I don't want to sounds preachy and contradictory, but before I wrote
this I agreed very strongly with you. I have experimented with git on
several occasions but before the latest release never considered it a
real possibility because it was so overly complicated. The new
interface is almost the exact same as every other distributed system,
the only real difference is that you don't change directories for each
branch you make. The 5 seconds primer for working from a centralized
system would be:

mkdir projdir && cd projdir
git clone ssh://[EMAIL PROTECTED]/git/coolproject/kkubasik
git branch newcoolfeature
git checkout newcoolfeature

git commit -a

Now you have 2 branches (the original, and newcoolfeature) where new
cool feature has your changes.


>
> > 4) A complete migration at this point is foolhardy, we just did a big
> > one, the sysadmin team is strained, and simply put, Subversion isn't
> > all that bad.
> > 5) Asking that translators and documenters learn a new (and radially
> > different) version control system is unreasonable. While the concepts
> > behind git may work and make great sense for a Computer Science major,
> > we would probably lose not only a lot of productive translator time
> > (which is unbelievably valuable as it is), but we might even lose
> > translators to the frustration of an overly complicated system.
>
> You have haven't investigated if Git is ok in the end for them in this
> proposal.
>
> E.g. can git checkout just one file, or just one directory? And be able
> to commit a new version back (I don't mean a 'svn cat' equivalent). Is
> there a GUI? Is it available on most distros (a version that will be
> ok), in the distro versions most translators/documenters have installed?
> etc.

This was discussed over at Debian,
http://www.mail-archive.com/[EMAIL PROTECTED]/msg11777.html

and they came to the conclusion that I realize isn't nearly as clear
as I hoped it would be. That distributed development in general is not
conducive to translation (at least in our current model)  the best bet
would probably be that for our 'main' repo there is a 'main-trans' or
similar that would only represent changes going into head. (Much the
same role as the subversion server would serve in the transition
period, only completed/accepted changesets would be pushed there.)

As for git being able to perform all the same tasks as Subversion
(like single file manipulations/checkouts) it can and does most of it
well. It's all available as a remote repo, however, given the size and
speed at which cloning a repo (even an enormous one) happens, its
completely realistic (from my limited understanding of the translators
workflow).

However, I am not a translator, or a wizard of Git or Subversion, but
this qualms a lot of those concerns, while raising some greater
implementation questions (like how realistic is it to require/ask that
devs keep a 'static' branch up to date for translations alone?


>
> > 6) 3rd party tools and build systems (including our own, like jhbuild)
> > will suffer from a change, and even moreso from a half-assed one. This
> > swings both ways, we don't want to implement a change to please some
> > that leaves the Gnome code hopelessly divided, but at the same time,
> > we don't want to end up with new projects that are close to gnome, or
> > indeed even officially part of it, moving their development away from
> > Gnome.
>
> It isn't 3rd party tools. Our tools will suffer badly. There are various
> (sysadmin, etc) things that depend on SVN. Those all have to be
> rewritten. That took a few months to complete last time (CVS->SVN).
>
Agreed, and it is for this reason that I propose a system which holds on to a
svn.gnome.org <---> git tip revision until we are completely p

Re: Git vs SVN (was: Can we improve things?)

[Olav Vitters]

On Sat, Sep 08, 2007 at 02:03:20AM +0300, Zeeshan Ali wrote:
> Hi!
> 
> On 9/7/07, Olav Vitters <[EMAIL PROTECTED]> wrote:
> > On Fri, Sep 07, 2007 at 11:57:19AM +0300, Zeeshan Ali wrote:
> > >About the svn access, all centralized VCS's are meant for
> > > dictatorships. If the gnome foundation really wants to improve the
> > > situation, i recommend moving to git or some other non-distributed VCS
> > > instead of brain-dead centralized svn for the following reason:
> >
> > This will take 12x longer than fixing the problem. We'll end up with a
> > workaround (as someone still finally has to commit).
> 
>How come? The developer with write-access to the main repo (who is
> acting as the proxy) would get the commits pushed to his repo from the
> other developer and he would just push them upstream along with his
> commits. As me and Kalle tried to point out, with git you have a lot
> of freedom to do things in many different ways, which isn't true about
> SVN.

This is a workaround. You have developers who only do small patches
against every module. Such a developer 

I agree that it would be easier if it existed. However, it doesn't and
it is a workaround.

> > Finally, people can
> > already use a D-SCM together with SVN (git/bzr/.. support SVN). So if
> > D-SCM would solve things, there wouldn't be an issue currently.
> 
>   As I mentioned in one of my previous emails, the problem would have
> been far too small to make a big fuss about it if either A. it was a
> matter of a git repo instead of an SVN repo or B. the proxy developer
> and the developer needing write access, had decided to use git
> together with git-svn at their end.

I fully agree. But it still doesn't solve the issue (only makes it
easier)... again, this is D-SCM vs client-server, while the issue is
providing access to the central repos.

> > > 1. Developers can clone the main repo and the maintainers (people with
> > > write-access) can just pull from their cloned repos. This way a
> > > developer won't really need write access and he'll just keep on
> > > committing his changes to his repo and inform the maintainer(s) about
> > > his newest cool changes and the maintainer(s) can pull those changes
> > > if they like/need them.
> >
> > I call that a workaround. The problem is the access to the main repos.
> > If the maintainer doesn't pull from every developer you end up with the
> > same problem. At one point someone needs to do something (give access to
> > something / pull).
> 
>The developer doesn't necessarily need to 'pull'. What you are
> addressing is just one of the many ways things can operate when Git is
> being used. Please read above. I mentioned at least two different
> modes of operation which are not mutually exclusive.

My main point is that the developer still doesn't have access to the
central repos. Nice, a maintainer can setup another repos and have some
way to to give access to the developer to commit there. It doesn't solve
the issue.

> > > 2. #1 is a generic advantage of using a non-distributed VCS but the
> > > reason i would go for git is speed: it's amazingly super fast in all
> > > it's operations and will save a lot of precious developer time.
> >
> > You are ignoring the drawbacks and that it won't solve this issue.
> 
>For example?

git?. windows support for once, but that is not my problem with
suggesting that Git solves creating accounts.

A developer will need to ask to each maintainer if he would people grant
him access in some way to have him commit to the maintainers git repos
(which might just be some local thing).

> > I am all for D-SCM, but it is not a hammer.
> 
>   That might be but they are much better than centralized SCMs, at
> least git is quite obviously superior to SVN.

In some ways, and worse in others.. even the Git vs SVN page points that
out.

> > > 3. No need to maintain two levels of changelog.
> >
> > That is not true. The ChangeLog requirement has been discussed before.
> > Suggest to read the archives for that discussion (here / d-d-l).
> 
>I searched the archive and topics of the mails i found, didn't seem
> relevant so it would be nice if you either provide me a link to the
> thread or summarize the conclusion. We are using SVN so ChangeLog
> requirement obviously makes sense but I can't imagine it making any
> sense at all in D-SCMs especially git since i can always get the
> changelog using `git log`.

You can always use 'svn log' as well. The main point is that 'oops, made
a typo' will appear in 'svn log', not in ChangeLog. That is why
ChangeLog is a requirement for some modules in SVN (others don't care).

> > > For details on why a good and
> > > self-respecting developer wouldn't ever consider using svn over git,
> > > you have to watch this presentation by Linus:
> > > http://video.google.com/videoplay?docid=-2199332044603874737 .
> >
> > Last time I watched this it only talked about the benefits of a
> > distributed SCM vs non-distributed SCM. Furth

Re: Git vs SVN (was: Can we improve things?)

[Olav Vitters]

On Fri, Sep 07, 2007 at 10:35:55PM -0400, Kevin Kubasik wrote:
> While I don't wish to sound trite, I do think almost everyone here
> knows what everyone else is going to say, and maybe trying to
> headstart the discussion is a bad move, and presumptuous, but allow me
> to throw out an idea.
> 
> I think we are more or less in agreement that:
> 1) git would lower the barrier of entry for new developers,
> 2) git offers some significant benefits  when it comes to sharing and
> tracking patches, specifically in the realm of testing and/or release
> branching.

And so does most of every D-SCM out there. I really don't like Git
(windows not being a priority, too complicated, SHA1 collision, etc).

> 4) A complete migration at this point is foolhardy, we just did a big
> one, the sysadmin team is strained, and simply put, Subversion isn't
> all that bad.
> 5) Asking that translators and documenters learn a new (and radially
> different) version control system is unreasonable. While the concepts
> behind git may work and make great sense for a Computer Science major,
> we would probably lose not only a lot of productive translator time
> (which is unbelievably valuable as it is), but we might even lose
> translators to the frustration of an overly complicated system.

You have haven't investigated if Git is ok in the end for them in this
proposal.

E.g. can git checkout just one file, or just one directory? And be able
to commit a new version back (I don't mean a 'svn cat' equivalent). Is
there a GUI? Is it available on most distros (a version that will be
ok), in the distro versions most translators/documenters have installed?
etc.

> 6) 3rd party tools and build systems (including our own, like jhbuild)
> will suffer from a change, and even moreso from a half-assed one. This
> swings both ways, we don't want to implement a change to please some
> that leaves the Gnome code hopelessly divided, but at the same time,
> we don't want to end up with new projects that are close to gnome, or
> indeed even officially part of it, moving their development away from
> Gnome.

It isn't 3rd party tools. Our tools will suffer badly. There are various
(sysadmin, etc) things that depend on SVN. Those all have to be
rewritten. That took a few months to complete last time (CVS->SVN). 

> That being said, I see the following as a bordering-on-sanity approach
> to use as a starting point for a realistic debate over weather Gnome
> should go distributed or not.

And then you go off on picking only one D-SCM system. IMO, I'd rather
setup something else.

> My proposal is centered around Gnome maintaining its centralized
> development style, while capitalizing on the availability of tools
> that make collaboration in such an environment much easier.
> 1) We establish a 'central' git repository, providing remote access
> via the native git client, and webdav or ftp (a firewall friendly
> protocol) and if the server can handle the load, rsync. Well call this
> setup git.gnome.org. It is important to note, that upon
> git.gnome.org's conception, there has been no formal migration of
> anything. This is simply a central place for the sharing of git
> repositories and branches.

Small nit: FTP is never going to be allowed. It has to be secure (webdav
-- with client certificates which nobody has currently, SSH, SFTP,
etc).. so in practice it will be SSH.

Main point: Why Git? It seems only because we have a few people
screaming 'Git!' the loudest. From what I've learned a few systems will
not be good enough: darcs (due to not being able to scale), monotone
(IIRC like Git, but worse), arch (obsolete).

I'd like a practical discussion between Bzr / Git / Hg for people who do
understand all the requirements.

> 2) Even with the addition of git.gnome.org, at this point, Subversion
> remains the final and master copy of all Gnome source. Individual
> projects are free to branch and merge and frolic as they please, but
> it is imperative that the Subversion trunk remain the tip of active
> development. Be that through the forwarding of patches through git
> systems, or as it always has taken place. However, new projects are
> asked to use git, and simply treat Subversion as the master branch,
> where all changes are eventually pushed at release time.

I disagree with 'new projects are asked to use git'. If such a thing is
setup, it'll be a test setup. If it breaks down, too bad.

> 3) At this point, if all has gone well, we allow evangelist project
> maintainers to move to git exclusively if they so desire, this will
> help us asses the migration tools and times for a realistic assessment
> of the next step.

You've ignored all the other possible D-SCM systems out there. Really, I
could do s/git/hg/ and have the same story. I'd really like someone to
use the latest version of git/bzr/hg for the first time, and write down
all the annoyances. Then use each tool for ~3 months, documenting the
process the whole time.
After that, we would have a mor

Re: Git vs SVN (was: Can we improve things?)

[Kalle Vahlman]

2007/9/8, Kevin Kubasik <[EMAIL PROTECTED]>:
[snip reasoning]
> That being said, I see the following as a bordering-on-sanity approach
> to use as a starting point for a realistic debate over weather Gnome
> should go distributed or not.
[snip plan]

+1 to your plan, although I think more effort right now should be
directed to submitting translations and documentation without touching
VCS.

In my eyes, that's the real problem here. The developers will always
squabble over the right editor, indentation and VCS since they
generally are interested in those things, benefit from better tools
and usually have the motivation to learn new stuff. Non-developers
don't since those are not tools they really should be using in the
first place, and changing them just makes it more difficult to
contribute.

So, first we need to create a tool to submit translation&documentation
stuff to VCS and after that we'll have more freedom to decide which
VCS makes most sense to use.

-- 
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list

Re: Git vs SVN (was: Can we improve things?)

[Kevin Kubasik]

While I don't wish to sound trite, I do think almost everyone here
knows what everyone else is going to say, and maybe trying to
headstart the discussion is a bad move, and presumptuous, but allow me
to throw out an idea.

I think we are more or less in agreement that:
1) git would lower the barrier of entry for new developers,
2) git offers some significant benefits  when it comes to sharing and
tracking patches, specifically in the realm of testing and/or release
branching.
3) git-svn is an acceptable and stable program, while we should not
base a system off of it, asking that developers do use it is not out
of the question.

4) A complete migration at this point is foolhardy, we just did a big
one, the sysadmin team is strained, and simply put, Subversion isn't
all that bad.
5) Asking that translators and documenters learn a new (and radially
different) version control system is unreasonable. While the concepts
behind git may work and make great sense for a Computer Science major,
we would probably lose not only a lot of productive translator time
(which is unbelievably valuable as it is), but we might even lose
translators to the frustration of an overly complicated system.
6) 3rd party tools and build systems (including our own, like jhbuild)
will suffer from a change, and even moreso from a half-assed one. This
swings both ways, we don't want to implement a change to please some
that leaves the Gnome code hopelessly divided, but at the same time,
we don't want to end up with new projects that are close to gnome, or
indeed even officially part of it, moving their development away from
Gnome.


That being said, I see the following as a bordering-on-sanity approach
to use as a starting point for a realistic debate over weather Gnome
should go distributed or not.

My proposal is centered around Gnome maintaining its centralized
development style, while capitalizing on the availability of tools
that make collaboration in such an environment much easier.
1) We establish a 'central' git repository, providing remote access
via the native git client, and webdav or ftp (a firewall friendly
protocol) and if the server can handle the load, rsync. Well call this
setup git.gnome.org. It is important to note, that upon
git.gnome.org's conception, there has been no formal migration of
anything. This is simply a central place for the sharing of git
repositories and branches.

2) Even with the addition of git.gnome.org, at this point, Subversion
remains the final and master copy of all Gnome source. Individual
projects are free to branch and merge and frolic as they please, but
it is imperative that the Subversion trunk remain the tip of active
development. Be that through the forwarding of patches through git
systems, or as it always has taken place. However, new projects are
asked to use git, and simply treat Subversion as the master branch,
where all changes are eventually pushed at release time.

3) At this point, if all has gone well, we allow evangelist project
maintainers to move to git exclusively if they so desire, this will
help us asses the migration tools and times for a realistic assessment
of the next step.

4) The final step would be the introduction of git clones of every
Subversion module. Luckily, if done over a fast LAN (or ideally,
harddisk) this can be done very quickly, even for long-history'ed
projects. In addition, these git clones would be updated at some
regular interval (say hourly... really depends on the realistic cost
of the operation, and how active SVN still is)

At this point we have something not dissimilar from launchpad's
vcs-imports component. In short, projects are free to work in either
system, the goal would be (in my mind) that most development happened
in git, revolving around its distributed and free flowing development
model. However, since with git all the changes going upstream can just
be merged into the maintainers branch, and (s)he can push those
changes to subversion, so we still have all our source history in one
format and one place, should we choose to not stick with git.

Known Issues:
* Potentially long 'split-code' period - Agreed, this could happen,
but the reason that we still require that subversion trunk represent
an accurate snapshot of development is so that the code can always be
found, and we have the full revision history, we are just embracing
the advantages of a distributed system, and encouraging the Gnome
community to embrace recent advances in technology.
**Fact Alert** This is not at all dissimilar from what Mozilla has
started doing with mercurial and CVS, by all reports, its working
quite well, and developers that where panicked over the complete move
to hg[1], have learned the tool, and are comfortable with it, if not
excited (Revision control isn't really something one can ever get to
happy about, its always 'in the way' to some extent)
* Doesn't address the translators learning new software component. -
Yes, it does, the beauty of forcing the 

Git vs SVN (was: Can we improve things?)

[Zeeshan Ali]

Hi!

On 9/7/07, Olav Vitters <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 07, 2007 at 11:57:19AM +0300, Zeeshan Ali wrote:
> >About the svn access, all centralized VCS's are meant for
> > dictatorships. If the gnome foundation really wants to improve the
> > situation, i recommend moving to git or some other non-distributed VCS
> > instead of brain-dead centralized svn for the following reason:
>
> This will take 12x longer than fixing the problem. We'll end up with a
> workaround (as someone still finally has to commit).

   How come? The developer with write-access to the main repo (who is
acting as the proxy) would get the commits pushed to his repo from the
other developer and he would just push them upstream along with his
commits. As me and Kalle tried to point out, with git you have a lot
of freedom to do things in many different ways, which isn't true about
SVN.

> Finally, people can
> already use a D-SCM together with SVN (git/bzr/.. support SVN). So if
> D-SCM would solve things, there wouldn't be an issue currently.

  As I mentioned in one of my previous emails, the problem would have
been far too small to make a big fuss about it if either A. it was a
matter of a git repo instead of an SVN repo or B. the proxy developer
and the developer needing write access, had decided to use git
together with git-svn at their end.

> > 1. Developers can clone the main repo and the maintainers (people with
> > write-access) can just pull from their cloned repos. This way a
> > developer won't really need write access and he'll just keep on
> > committing his changes to his repo and inform the maintainer(s) about
> > his newest cool changes and the maintainer(s) can pull those changes
> > if they like/need them.
>
> I call that a workaround. The problem is the access to the main repos.
> If the maintainer doesn't pull from every developer you end up with the
> same problem. At one point someone needs to do something (give access to
> something / pull).

   The developer doesn't necessarily need to 'pull'. What you are
addressing is just one of the many ways things can operate when Git is
being used. Please read above. I mentioned at least two different
modes of operation which are not mutually exclusive.

> > 2. #1 is a generic advantage of using a non-distributed VCS but the
> > reason i would go for git is speed: it's amazingly super fast in all
> > it's operations and will save a lot of precious developer time.
>
> You are ignoring the drawbacks and that it won't solve this issue.

   For example?

> I am all for D-SCM, but it is not a hammer.

  That might be but they are much better than centralized SCMs, at
least git is quite obviously superior to SVN.

> > 3. No need to maintain two levels of changelog.
>
> That is not true. The ChangeLog requirement has been discussed before.
> Suggest to read the archives for that discussion (here / d-d-l).

   I searched the archive and topics of the mails i found, didn't seem
relevant so it would be nice if you either provide me a link to the
thread or summarize the conclusion. We are using SVN so ChangeLog
requirement obviously makes sense but I can't imagine it making any
sense at all in D-SCMs especially git since i can always get the
changelog using `git log`.

> > For details on why a good and
> > self-respecting developer wouldn't ever consider using svn over git,
> > you have to watch this presentation by Linus:
> > http://video.google.com/videoplay?docid=-2199332044603874737 .
>
> Last time I watched this it only talked about the benefits of a
> distributed SCM vs non-distributed SCM. Further, the style of presenting
> is very flame-ish. It only serves as advocacy to perhaps try some other
> D-SCM.

  You need to look at it a bit objectively. Linus says "you are stupid
and ugly" because you truly are stupid if you prefer to use SVN or any
centralized SCM and he clearly points out most of the reason why this
it the honest truth.

> Btw, generalising my arguments against git to 'sucky UI' is
> a misrepresentation.

   I won't commit that mistake but i didn't really see any other
convincing argument either. :)

-- 
Regards,

Zeeshan Ali
FSF member#5124
___
foundation-list mailing list
foundation-list@gnome.org
http://mail.gnome.org/mailman/listinfo/foundation-list