From nextgens at freenetproject.org  Tue Jul  1 04:02:06 2008
From: nextgens at freenetproject.org (NextGen$)
Date: Tue, 1 Jul 2008 04:02:06 +0000
Subject: [Tech] Switch Repository to Git
In-Reply-To: <200806300031.03920.bombe@pterodactylus.net>
References: <200806300031.03920.bombe@pterodactylus.net>
Message-ID: <20080701040206.GB26659@freenetproject.org>

* David ???Bombe??? Roden <bombe at pterodactylus.net> [2008-06-30 00:31:03]:

> Hey folks,
> 
> I have been looking at and working with Git for the last four or five weeks 
> and I must say that I???m very impressed by it. It???s easy to use,

We must have different definitions of the word "easy" :)

> it???s extremely powerful,

granted

> it enables developers to perform the most tedious tasks 
> in a very short time and in general simply wipes the floor with 
> subversion. :)
> 

Here I don't agree; they are targetting a different audience, hence they
provide a different set of functionnalities... and have different problems.

> It is possible to import subversion repositories into Git, keeping the 
> complete history and even branches, and it???s even possible to commit changes 
> made in a local repository back to subversion; I just tested that tonight 
> when I fixed nextgens??? backport of toad???s BucketChainBucket???it even made 
> finding the bug simple.
> 

We all agree that that merging things from branches back and forth is not
easy with svn 1.4... but it will be easier when we will upgrade to a
merge-tracking enabled version.

> Git repositories can be served by a special git-daemon or by a normal, 
> run-off-the-mill HTTP server without any special modules. No DAV, no CGI, no 
> nothing, just plain HTTP.
> 
> I???d suggest that we move to Git rather sooner than later;

What feature does it have we would *need* ?
Since 0.7 started we had something like 6 branches... Even though I agree
that the merging tool is under-optimized, I think we can live with it.

First of all I am not convinced that we want to use a DSCM... and as for
the choice of GIT, well, I don't think it's appropriate in our usecase
for the following reasons:
	- Its user interface sucks (even the git guys acknowledge that and
	  that's why they developped many front-ends to git like cogito)
	- Its documentation is inexistent
	- Its integration to IDEs sucks
	- Its not cross-platform, contrary to SVN
	- As far as I know it's not possible to integrate it with mantis, nor
	  to auto-link svn revision numbers filled into tickets to commit
	  identifiers git uses.
	- It's a DSCM ... DSCMs concepts are more complicated to apprehend
	  than SCMs concepts for the average guy; We try to lower the fence
	  the average contributor has to pass in order to be able to
	  contribute; not to higher it.
	- DSCMs encourage forking; that's definitly not something we want to
	  do.

To be fair, on the assets side we have:
	- makes anonymous development easier (but we didn't have many anon.
	  contributors... and I doubt it's related to the tools)
	- Working copies are smaller as they aren't per-branch.
	- It's probably faster than SVN when you work locally and don't push
	  your changes.

> most of the trouble 
> we had with bug #2440 (which resulted from the faulty backport) would never 
> have occured in the first place with Git. (Sure, of course you can make 
> changes in the wrong branch but Git will happily apply a commit from one 
> branch to another so the backport could have been done in two minutes.)
> 

Well, I was aware it was broken but didn't take the time to fix it before I
left...

> Anybody in favor? Anybody opposed?
> 

I'm opposed but I guess you already know it if you read that email up to
here :)

Florent


From j16sdiz+freenet at gmail.com  Tue Jul  1 06:45:04 2008
From: j16sdiz+freenet at gmail.com (Daniel Cheng)
Date: Tue, 1 Jul 2008 14:45:04 +0800
Subject: [Tech] Switch Repository to Git
In-Reply-To: <20080701040206.GB26659@freenetproject.org>
References: <200806300031.03920.bombe@pterodactylus.net>
	<20080701040206.GB26659@freenetproject.org>
Message-ID: <ff6a9c820806302345u441a32fqa71a774bde7ea746@mail.gmail.com>

On Tue, Jul 1, 2008 at 12:02 PM, NextGen$ <nextgens at freenetproject.org> wrote:
> * David ???Bombe??? Roden <bombe at pterodactylus.net> [2008-06-30 00:31:03]:
>
>> Hey folks,
>>
>> I have been looking at and working with Git for the last four or five weeks
>> and I must say that I???m very impressed by it. It???s easy to use,
>
> We must have different definitions of the word "easy" :)
>
>> it???s extremely powerful,
>
> granted
>
>> it enables developers to perform the most tedious tasks
>> in a very short time and in general simply wipes the floor with
>> subversion. :)
>>
>
> Here I don't agree; they are targetting a different audience, hence they
> provide a different set of functionnalities... and have different problems.
>
>> It is possible to import subversion repositories into Git, keeping the
>> complete history and even branches, and it???s even possible to commit changes
>> made in a local repository back to subversion; I just tested that tonight
>> when I fixed nextgens??? backport of toad???s BucketChainBucket???it even made
>> finding the bug simple.
>>
>
> We all agree that that merging things from branches back and forth is not
> easy with svn 1.4... but it will be easier when we will upgrade to a
> merge-tracking enabled version.
>
>> Git repositories can be served by a special git-daemon or by a normal,
>> run-off-the-mill HTTP server without any special modules. No DAV, no CGI, no
>> nothing, just plain HTTP.
>>
>> I???d suggest that we move to Git rather sooner than later;
>
> What feature does it have we would *need* ?
> Since 0.7 started we had something like 6 branches... Even though I agree
> that the merging tool is under-optimized, I think we can live with it.
>
> First of all I am not convinced that we want to use a DSCM... and as for
> the choice of GIT, well, I don't think it's appropriate in our usecase
> for the following reasons:
>        - Its user interface sucks (even the git guys acknowledge that and
>          that's why they developped many front-ends to git like cogito)

That's many years ago. The cogito project have ended, and some of the
feature have been merged to the mainline. Lots of the frontend and
documentation have been rewritten dueing the process.

>        - Its documentation is inexistent

Same as above.

>        - Its integration to IDEs sucks
>        - Its not cross-platform, contrary to SVN

It is cross-platform. It work well on mingw32 and cygwin.

>        - As far as I know it's not possible to integrate it with mantis, nor
>          to auto-link svn revision numbers filled into tickets to commit
>          identifiers git uses.

This is a general problem for DSCM.

>        - It's a DSCM ... DSCMs concepts are more complicated to apprehend
>          than SCMs concepts for the average guy; We try to lower the fence
>          the average contributor has to pass in order to be able to
>          contribute; not to higher it.

average contributor just send in small, self contained patch.

>        - DSCMs encourage forking; that's definitly not something we want to
>          do.

for anonymous development, we *need* private branch and forking.

> To be fair, on the assets side we have:
>        - makes anonymous development easier (but we didn't have many anon.
>          contributors... and I doubt it's related to the tools)

If we want to encourage anonymous contribution, a DSCM is preferred..
This allow the contributor keep a private branch while waiting for
review / merge.

I know we don't want to accept anonymous contribution now (for legal reason),
but we have to do this sooner or later due to the nature of freenet.
(development of freenet *will* be outlawed in most country in a few years..)

>        - Working copies are smaller as they aren't per-branch.
>        - It's probably faster than SVN when you work locally and don't push
>          your changes.
>
>> most of the trouble
>> we had with bug #2440 (which resulted from the faulty backport) would never
>> have occured in the first place with Git. (Sure, of course you can make
>> changes in the wrong branch but Git will happily apply a commit from one
>> branch to another so the backport could have been done in two minutes.)
>>
>
> Well, I was aware it was broken but didn't take the time to fix it before I
> left...
>
>> Anybody in favor? Anybody opposed?
>>
>
> I'm opposed but I guess you already know it if you read that email up to
> here :)

How about Mercurial? Will you support migrating to it?
It have much better IDE support and cross platform support.
(while keeping the other "disadvantages")

Plus, there are three different freenet+hg integrations.

We need a DSCM that work over freenet before it is outlawed in most country.
(I prefer git)

--


From bombe at pterodactylus.net  Tue Jul  1 17:23:16 2008
From: bombe at pterodactylus.net (David =?utf-8?q?=E2=80=98Bombe=E2=80=99_Roden?=)
Date: Tue, 1 Jul 2008 19:23:16 +0200
Subject: [Tech] Switch Repository to Git
In-Reply-To: <20080701040206.GB26659@freenetproject.org>
References: <200806300031.03920.bombe@pterodactylus.net>
	<20080701040206.GB26659@freenetproject.org>
Message-ID: <200807011923.20243.bombe@pterodactylus.net>

On Tuesday 01 July 2008 06:02:06 NextGen$ wrote:

>> I have been looking at and working with Git for the last four or five
>> weeks and I must say that I???m very impressed by it. It???s easy to use,
> We must have different definitions of the word "easy" :)

I don?t know about your definition of ?easy? but mine matches what it says in 
dictionaries. ;)

Anything subversion can do Git can do as well and most of it is simpler. 
Granted, what takes a while to grasp is the concept of begin commit-based 
instead of revision-based. But once you got that you _have_ to marvel at its 
beauty. :)


> Here I don't agree; they are targetting a different audience, hence they
> provide a different set of functionnalities... and have different problems.

I?m not so sure about that. Sure, when Git was conceived being distributed was 
a key requirement. But saying that DSCMs are only something for a small part 
of all developers it wrong, IMHO. SCM is for every developer?whether it?s 
distributed or not is a minor concern.


> We all agree that that merging things from branches back and forth is not
> easy with svn 1.4... but it will be easier when we will upgrade to a
> merge-tracking enabled version.

In subversion it will always be a cludge, though, because subversion wasn?t 
designed with repeated merges in mind.


> What feature does it have we would *need* ?
> Since 0.7 started we had something like 6 branches... 

Actually, the six branches we have are all there have been since 0.4.0 (at 
least that?s the first commit in the subversion repository says). :)

But I think that having six branches is a symptom of using subversion because 
heavy branching and merging is basically impossible in subversion without a 
lot of manual work. We not using subversion because we don?t branch a lot but 
we don?t branch a lot because we are using subversion.

I never used to branch much when I used subversion; now with Git I branch a 
whole lot more. It?s easy, it keeps your construction sites apart, and 
merging the branches back into some mainline branch is a breeze. With 
subversion I was always very hesitant with merging branches back because I 
had to keep track manually of when I merged what into where.


> First of all I am not convinced that we want to use a DSCM... 

Why not? Why is a DSCM so fundamentally different? Why would it not be 
appropriate for freenet? (You can still have a central repository that all 
main developers keep pushing their work into and that acts as a source of 
reference for other. Plus, because of all that cryptographic stuff we 
wouldn?t have to host it ourselfs. If somebody messes with it, we?d notice.)


> as for  the choice of GIT, well, I don't think it's appropriate in our 
> usecase for the following reasons:
> 	- Its user interface sucks (even the git guys acknowledge that and
> 	  that's why they developped many front-ends to git like cogito)
> 	- Its documentation is inexistent

As Daniel already pointed out, these points are no longer valid. A lot of work 
has been done and is still being done.


> 	- As far as I know it's not possible to integrate it with mantis, nor
> 	  to auto-link svn revision numbers filled into tickets to commit
> 	  identifiers git uses.

XMMS2?s mantis[1] is somehow tied into their Git repository. For example [2] 
shows that an issue was automatically resolved when the fix was committed.


> 	- It's a DSCM ... DSCMs concepts are more complicated to apprehend
> 	  than SCMs concepts for the average guy; We try to lower the fence
> 	  the average contributor has to pass in order to be able to
> 	  contribute; not to higher it.

The average contributor is as capable to follow instructions for a Git 
repository as he is capable to follow instructions for a subversion 
repository. You don?t to know much about the SCM in use to create a patch. 
You can even get by completely without using any SCM.


> 	- DSCMs encourage forking; that's definitly not something we want to
> 	  do.

That nobody forked freenet (0.7 at least) is not a matter of the SCM we use; 
it?s a matter of nobody understanding the ultra-convoluted codebase. :)


> 	- It's probably faster than SVN when you work locally and don't push
> 	  your changes.

Even when pushing over the network it?s a lot faster. The transfer itself is 
tiny and as the repository that does the integration is locally fast as well, 
it?s faster overall. I can check out the linux Git repository in about 8 
minutes and that carries the _complete_ history since 2.6.13. A clone of 
freenet?s subversion repository with all commits takes several _hours_, and 
it?s a lot smaller.


> Well, I was aware it was broken but didn't take the time to fix it before I
> left...

Yes, but that?s not the point. With Git, toad (or anybody else) could have 
git-cherry-pick?d the three (or so) commits and applied them to trunk in a 
matter of minutes. Okay, subversion can merge a revision range into another 
branch as well but it will seriously barf when you try to merge the two 
complete branches together later. Git would happily skip those commits as 
they already have been applied. Also, it?s not the point here that toad 
should have done the fix on trunk to begin with. ;)


> I'm opposed but I guess you already know it if you read that email up to
> here :)

Yeah, well, I gathered that. I still hope that Git is not completely out of 
the window yet. It is a great system which I think would make our lifes at 
least a bit easier.


> Florent

	David


[1] http://bugs.xmms2.xmms.se/
[2] http://bugs.xmms2.xmms.se/view.php?id=1994
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://emu.freenetproject.org/pipermail/tech/attachments/20080701/6544e401/attachment.pgp 

From alejandro at mosteo.com  Wed Jul  2 08:02:32 2008
From: alejandro at mosteo.com (Jano)
Date: Wed, 02 Jul 2008 10:02:32 +0200
Subject: [Tech] Switch Repository to Git
References: <200806300031.03920.bombe@pterodactylus.net>
	<20080701040206.GB26659@freenetproject.org>
	<200807011923.20243.bombe@pterodactylus.net>
Message-ID: <g4fcmf$pgm$1@ger.gmane.org>

David ?Bombe? Roden wrote:

> On Tuesday 01 July 2008 06:02:06 NextGen$ wrote:
> 
>> We all agree that that merging things from branches back and forth is not
>> easy with svn 1.4... but it will be easier when we will upgrade to a
>> merge-tracking enabled version.
> 
> In subversion it will always be a cludge, though, because subversion wasn?t
> designed with repeated merges in mind.

Have you read the svn 1.5 release notes? You'd still call it a kludge? I'm
honestly asking, I'd like to know from someone used to git.

>> Florent
> 
> David



From nextgens at freenetproject.org  Wed Jul  2 14:03:31 2008
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Wed, 2 Jul 2008 16:03:31 +0200
Subject: [Tech] Switch Repository to Git
In-Reply-To: <200807011923.20243.bombe@pterodactylus.net>
References: <200806300031.03920.bombe@pterodactylus.net>
	<20080701040206.GB26659@freenetproject.org>
	<200807011923.20243.bombe@pterodactylus.net>
Message-ID: <20080702140329.GB3513@freenetproject.org>

* David ???Bombe??? Roden <bombe at pterodactylus.net> [2008-07-01 19:23:16]:

> On Tuesday 01 July 2008 06:02:06 NextGen$ wrote:
> 
> >> I have been looking at and working with Git for the last four or five
> >> weeks and I must say that I???m very impressed by it. It???s easy to use,
> > We must have different definitions of the word "easy" :)
> 
> I don???t know about your definition of ???easy??? but mine matches what it says in 
> dictionaries. ;)
> 
> Anything subversion can do Git can do as well and most of it is simpler. 
> Granted, what takes a while to grasp is the concept of begin commit-based 
> instead of revision-based. But once you got that you _have_ to marvel at its 
> beauty. :)
> 
> 
> > Here I don't agree; they are targetting a different audience, hence they
> > provide a different set of functionnalities... and have different problems.
> 
> I???m not so sure about that. Sure, when Git was conceived being distributed was 
> a key requirement. But saying that DSCMs are only something for a small part 
> of all developers it wrong, IMHO. SCM is for every developer???whether it???s 
> distributed or not is a minor concern.
> 

No, it's not a minor concern; it affects the team-work and more
generally speaking the way the application is developed.

> 
> > We all agree that that merging things from branches back and forth is not
> > easy with svn 1.4... but it will be easier when we will upgrade to a
> > merge-tracking enabled version.
> 
> In subversion it will always be a cludge, though, because subversion wasn???t 
> designed with repeated merges in mind.
> 

Could you elaborate please ?
Starting with svn 1.5 each commit has both a revision number and a
"merge identifier" (I'm not sure about the terminology here). Git has
only one of those.

> 
> > What feature does it have we would *need* ?
> > Since 0.7 started we had something like 6 branches... 
> 
> Actually, the six branches we have are all there have been since 0.4.0 (at 
> least that???s the first commit in the subversion repository says). :)
> 
> But I think that having six branches is a symptom of using subversion because 
> heavy branching and merging is basically impossible in subversion without a 
> lot of manual work. We not using subversion because we don???t branch a lot but 
> we don???t branch a lot because we are using subversion.
> 

Blaming the tools is easy. That's also what we did regarding "why the
website isn't updated" and "why aren't people reviewing commits
consistently"; In both occurrences experience has shown that changing
the tools didn't help.

> I never used to branch much when I used subversion; now with Git I branch a 
> whole lot more. It???s easy, it keeps your construction sites apart, and 
> merging the branches back into some mainline branch is a breeze.

huh ? to me it's hard to make simpler than "svn cp"

> With 
> subversion I was always very hesitant with merging branches back because I 
> had to keep track manually of when I merged what into where.
> 

That's not a concern anymore with merge-tracking as implemented in svn
1.5

> 
> > First of all I am not convinced that we want to use a DSCM... 
> 
> Why not? Why is a DSCM so fundamentally different? Why would it not be 
> appropriate for freenet? (You can still have a central repository that all 
> main developers keep pushing their work into and that acts as a source of 
> reference for other. Plus, because of all that cryptographic stuff we 
> wouldn???t have to host it ourselfs. If somebody messes with it, we???d notice.)
> 
> 
> > as for  the choice of GIT, well, I don't think it's appropriate in our 
> > usecase for the following reasons:
> > 	- Its user interface sucks (even the git guys acknowledge that and
> > 	  that's why they developped many front-ends to git like cogito)
> > 	- Its documentation is inexistent
> 
> As Daniel already pointed out, these points are no longer valid. A lot of work 
> has been done and is still being done.
> 

I recon. that I did look into it a while ago and that it may have
changed :)

> 
> > 	- As far as I know it's not possible to integrate it with mantis, nor
> > 	  to auto-link svn revision numbers filled into tickets to commit
> > 	  identifiers git uses.
> 
> XMMS2???s mantis[1] is somehow tied into their Git repository. For example [2] 
 shows that an issue was automatically resolved when the fix was committed.
> 
> 
> > 	- It's a DSCM ... DSCMs concepts are more complicated to apprehend
> > 	  than SCMs concepts for the average guy; We try to lower the fence
> > 	  the average contributor has to pass in order to be able to
> > 	  contribute; not to higher it.
> 
> The average contributor is as capable to follow instructions for a Git 
> repository as he is capable to follow instructions for a subversion 
> repository. You don???t to know much about the SCM in use to create a patch. 
> You can even get by completely without using any SCM.
> 

That's exactly what we want to prevent. If the tools are too complicated
people won't use them and we will end up limiting the number of
"commiters"... The asset of SCMs is traceability; we want to know to who
belong each single line of code we host; That might be useful in case we
want to re-license the code or something.

> 
> > 	- DSCMs encourage forking; that's definitly not something we want to
> > 	  do.
> 
> That nobody forked freenet (0.7 at least) is not a matter of the SCM we use; 
> it???s a matter of nobody understanding the ultra-convoluted codebase. :)
> 
> 
> > 	- It's probably faster than SVN when you work locally and don't push
> > 	  your changes.
> 
> Even when pushing over the network it???s a lot faster. The transfer itself is 
> tiny and as the repository that does the integration is locally fast as well, 
> it???s faster overall. I can check out the linux Git repository in about 8 
> minutes and that carries the _complete_ history since 2.6.13. A clone of 
> freenet???s subversion repository with all commits takes several _hours_, and 
> it???s a lot smaller.
> 

As far as I know git doesn't handle sparse checkouts. That alone is a
good reason why not to use it :)

I do not have a full checkout of the trunk here... and I see no point in
having one; I don't buy the "it will take less space" argument.

> 
> > Well, I was aware it was broken but didn't take the time to fix it before I
> > left...
> 
> Yes, but that???s not the point. With Git, toad (or anybody else) could have 
> git-cherry-pick???d the three (or so) commits and applied them to trunk in a 
> matter of minutes. Okay, subversion can merge a revision range into another 
> branch as well but it will seriously barf when you try to merge the two 
> complete branches together later. Git would happily skip those commits as 
> they already have been applied. Also, it???s not the point here that toad 
> should have done the fix on trunk to begin with. ;)
> 

svn 1.5's merge tracking is solving that problem

> 
> > I'm opposed but I guess you already know it if you read that email up to
> > here :)
> 
> Yeah, well, I gathered that. I still hope that Git is not completely out of 
> the window yet. It is a great system which I think would make our lifes at 
> least a bit easier.

No one prevent you from using it; we might even consider publishing an
officially converted, read-only tree... but for now, using it as our
main SCM is out of question:

Quote from IRC:
"
[13:33] <@   nextgens> | toad_> any views regarding a switch to a dscm ?
[13:34] <      toad_> | nextgens: broadly in favour but sceptical in
the short run, we have limited time
[13:34] <@   nextgens> | okay so we agree :)
"

Florent
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/tech/attachments/20080702/d3510953/attachment.pgp 

From j16sdiz+freenet at gmail.com  Wed Jul  2 15:21:45 2008
From: j16sdiz+freenet at gmail.com (Daniel Cheng)
Date: Wed, 2 Jul 2008 23:21:45 +0800
Subject: [Tech] Switch Repository to Git
In-Reply-To: <g4fcmf$pgm$1@ger.gmane.org>
References: <200806300031.03920.bombe@pterodactylus.net>
	<20080701040206.GB26659@freenetproject.org>
	<200807011923.20243.bombe@pterodactylus.net>
	<g4fcmf$pgm$1@ger.gmane.org>
Message-ID: <ff6a9c820807020821of39c53dnb1991530c043c42c@mail.gmail.com>

On Wed, Jul 2, 2008 at 4:02 PM, Jano <alejandro at mosteo.com> wrote:
> David 'Bombe' Roden wrote:
>
>> On Tuesday 01 July 2008 06:02:06 NextGen$ wrote:
>>
>>> We all agree that that merging things from branches back and forth is not
>>> easy with svn 1.4... but it will be easier when we will upgrade to a
>>> merge-tracking enabled version.
>>
>> In subversion it will always be a cludge, though, because subversion wasn't
>> designed with repeated merges in mind.
>
> Have you read the svn 1.5 release notes? You'd still call it a kludge? I'm
> honestly asking, I'd like to know from someone used to git.

While I love using git, I am more interesting in DSCM then any
specific SCM. The ability of commit locally and work offline allow me
to test out my idea more freely.
You know, everybody have some crazy idea that he want to test without
letting others to see.
For instance, I have yet another experimental database and an
alternative location swapping code locally.

A (good) side effect is the ability to work offline.

Easy merge management is just a side effect of DSCM -- DSCM encourage
branching and forking. That's why every DSCM comes with a set of good
merging tools.


From nextgens at freenetproject.org  Wed Jul  2 15:24:35 2008
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Wed, 2 Jul 2008 17:24:35 +0200
Subject: [Tech] Switch Repository to Git
In-Reply-To: <ff6a9c820807020821of39c53dnb1991530c043c42c@mail.gmail.com>
References: <200806300031.03920.bombe@pterodactylus.net>
	<20080701040206.GB26659@freenetproject.org>
	<200807011923.20243.bombe@pterodactylus.net>
	<g4fcmf$pgm$1@ger.gmane.org>
	<ff6a9c820807020821of39c53dnb1991530c043c42c@mail.gmail.com>
Message-ID: <20080702152433.GD3513@freenetproject.org>

* Daniel Cheng <j16sdiz+freenet at gmail.com> [2008-07-02 23:21:45]:

> On Wed, Jul 2, 2008 at 4:02 PM, Jano <alejandro at mosteo.com> wrote:
> > David 'Bombe' Roden wrote:
> >
> >> On Tuesday 01 July 2008 06:02:06 NextGen$ wrote:
> >>
> >>> We all agree that that merging things from branches back and forth is not
> >>> easy with svn 1.4... but it will be easier when we will upgrade to a
> >>> merge-tracking enabled version.
> >>
> >> In subversion it will always be a cludge, though, because subversion wasn't
> >> designed with repeated merges in mind.
> >
> > Have you read the svn 1.5 release notes? You'd still call it a kludge? I'm
> > honestly asking, I'd like to know from someone used to git.
> 
> While I love using git, I am more interesting in DSCM then any
> specific SCM. The ability of commit locally and work offline allow me
> to test out my idea more freely.
> You know, everybody have some crazy idea that he want to test without
> letting others to see.
> For instance, I have yet another experimental database and an
> alternative location swapping code locally.
> 
> A (good) side effect is the ability to work offline.
> 
> Easy merge management is just a side effect of DSCM -- DSCM encourage
> branching and forking. That's why every DSCM comes with a set of good
> merging tools.

That's my point: at this stage we don't want to encourage branching nor
forking.

We need the network to be homogeneous version and bug-wise to be debuggable
and to move forward.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/tech/attachments/20080702/1cb5f506/attachment.pgp 

From j16sdiz+freenet at gmail.com  Wed Jul  2 15:34:29 2008
From: j16sdiz+freenet at gmail.com (Daniel Cheng)
Date: Wed, 2 Jul 2008 23:34:29 +0800
Subject: [Tech] Switch Repository to Git
In-Reply-To: <20080702152433.GD3513@freenetproject.org>
References: <200806300031.03920.bombe@pterodactylus.net>
	<20080701040206.GB26659@freenetproject.org>
	<200807011923.20243.bombe@pterodactylus.net>
	<g4fcmf$pgm$1@ger.gmane.org>
	<ff6a9c820807020821of39c53dnb1991530c043c42c@mail.gmail.com>
	<20080702152433.GD3513@freenetproject.org>
Message-ID: <ff6a9c820807020834h38e1b499r9da1ccc630d6b322@mail.gmail.com>

2008/7/2 Florent Daigni?re <nextgens at freenetproject.org>:
> * Daniel Cheng <j16sdiz+freenet at gmail.com> [2008-07-02 23:21:45]:
>
>> On Wed, Jul 2, 2008 at 4:02 PM, Jano <alejandro at mosteo.com> wrote:
>> > David 'Bombe' Roden wrote:
>> >
>> >> On Tuesday 01 July 2008 06:02:06 NextGen$ wrote:
>> >>
>> >>> We all agree that that merging things from branches back and forth is not
>> >>> easy with svn 1.4... but it will be easier when we will upgrade to a
>> >>> merge-tracking enabled version.
>> >>
>> >> In subversion it will always be a cludge, though, because subversion wasn't
>> >> designed with repeated merges in mind.
>> >
>> > Have you read the svn 1.5 release notes? You'd still call it a kludge? I'm
>> > honestly asking, I'd like to know from someone used to git.
>>
>> While I love using git, I am more interesting in DSCM then any
>> specific SCM. The ability of commit locally and work offline allow me
>> to test out my idea more freely.
>> You know, everybody have some crazy idea that he want to test without
>> letting others to see.
>> For instance, I have yet another experimental database and an
>> alternative location swapping code locally.
>>
>> A (good) side effect is the ability to work offline.
>>
>> Easy merge management is just a side effect of DSCM -- DSCM encourage
>> branching and forking. That's why every DSCM comes with a set of good
>> merging tools.
>
> That's my point: at this stage we don't want to encourage branching nor
> forking.

The tools make this easier does not means we have to encourage it.

> We need the network to be homogeneous version and bug-wise to be debuggable
> and to move forward.

Anyway, you can't stop me (or anybody else) from using git-svn locally
(and I am using it).

--


From alejandro at mosteo.com  Wed Jul  2 16:08:37 2008
From: alejandro at mosteo.com (Jano)
Date: Wed, 02 Jul 2008 18:08:37 +0200
Subject: [Tech] Switch Repository to Git
References: <200806300031.03920.bombe@pterodactylus.net>
	<20080701040206.GB26659@freenetproject.org>
	<200807011923.20243.bombe@pterodactylus.net>
	<g4fcmf$pgm$1@ger.gmane.org>
	<ff6a9c820807020821of39c53dnb1991530c043c42c@mail.gmail.com>
Message-ID: <g4g95r$aff$1@ger.gmane.org>

Daniel Cheng wrote:

> On Wed, Jul 2, 2008 at 4:02 PM, Jano
> <alejandro at mosteo.com> wrote:
>> David 'Bombe' Roden wrote:
>>
>>> On Tuesday 01 July 2008 06:02:06 NextGen$ wrote:
>>>
>>>> We all agree that that merging things from branches back and forth is not
>>>> easy with svn 1.4... but it will be easier when we will upgrade to a
>>>> merge-tracking enabled version.
>>>
>>> In subversion it will always be a cludge, though, because subversion wasn't
>>> designed with repeated merges in mind.
>>
>> Have you read the svn 1.5 release notes? You'd still call it a kludge? I'm
>> honestly asking, I'd like to know from someone used to git.
> 
> While I love using git, I am more interesting in DSCM then any
> specific SCM. The ability of commit locally and work offline allow me
> to test out my idea more freely.
> You know, everybody have some crazy idea that he want to test without
> letting others to see.
> For instance, I have yet another experimental database and an
> alternative location swapping code locally.
> 
> A (good) side effect is the ability to work offline.
> 
> Easy merge management is just a side effect of DSCM -- DSCM encourage
> branching and forking. That's why every DSCM comes with a set of good
> merging tools.

Well -- (leaving aside my unanswered question ;) ) -- I'm asking because for my
own data (note -- not only code) I use svn, and merge tracking will be
welcome. But I wonder what you (or `Bombe') consider a kludge and what not.

Certainly I can see advantages to DSCM, but I don't feel for now a pressing
need to move from svn for my non-collaborative needs.



From nextgens at freenetproject.org  Wed Jul  2 16:11:17 2008
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Wed, 2 Jul 2008 18:11:17 +0200
Subject: [Tech] Switch Repository to Git
In-Reply-To: <ff6a9c820807020834h38e1b499r9da1ccc630d6b322@mail.gmail.com>
References: <200806300031.03920.bombe@pterodactylus.net>
	<20080701040206.GB26659@freenetproject.org>
	<200807011923.20243.bombe@pterodactylus.net>
	<g4fcmf$pgm$1@ger.gmane.org>
	<ff6a9c820807020821of39c53dnb1991530c043c42c@mail.gmail.com>
	<20080702152433.GD3513@freenetproject.org>
	<ff6a9c820807020834h38e1b499r9da1ccc630d6b322@mail.gmail.com>
Message-ID: <20080702161116.GE3513@freenetproject.org>

* Daniel Cheng <j16sdiz+freenet at gmail.com> [2008-07-02 23:34:29]:

> 2008/7/2 Florent Daigni?re <nextgens at freenetproject.org>:
> > * Daniel Cheng <j16sdiz+freenet at gmail.com> [2008-07-02 23:21:45]:
> >
> >> On Wed, Jul 2, 2008 at 4:02 PM, Jano <alejandro at mosteo.com> wrote:
> >> > David 'Bombe' Roden wrote:
> >> >
> >> >> On Tuesday 01 July 2008 06:02:06 NextGen$ wrote:
> >> >>
> >> >>> We all agree that that merging things from branches back and forth is not
> >> >>> easy with svn 1.4... but it will be easier when we will upgrade to a
> >> >>> merge-tracking enabled version.
> >> >>
> >> >> In subversion it will always be a cludge, though, because subversion wasn't
> >> >> designed with repeated merges in mind.
> >> >
> >> > Have you read the svn 1.5 release notes? You'd still call it a kludge? I'm
> >> > honestly asking, I'd like to know from someone used to git.
> >>
> >> While I love using git, I am more interesting in DSCM then any
> >> specific SCM. The ability of commit locally and work offline allow me
> >> to test out my idea more freely.
> >> You know, everybody have some crazy idea that he want to test without
> >> letting others to see.
> >> For instance, I have yet another experimental database and an
> >> alternative location swapping code locally.
> >>
> >> A (good) side effect is the ability to work offline.
> >>
> >> Easy merge management is just a side effect of DSCM -- DSCM encourage
> >> branching and forking. That's why every DSCM comes with a set of good
> >> merging tools.
> >
> > That's my point: at this stage we don't want to encourage branching nor
> > forking.
> 
> The tools make this easier does not means we have to encourage it.
> 

Sure but why should we make it easier if it's not to encourage it then ?
:)

> > We need the network to be homogeneous version and bug-wise to be debuggable
> > and to move forward.
> 
> Anyway, you can't stop me (or anybody else) from using git-svn locally
> (and I am using it).
> 

I have no problem with you (or anybody else) using the tools they want.
I just don't want brazillion of incompatible/forked clients to spawn up
in the wild and to connect to the main network.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/tech/attachments/20080702/8e6f6d9d/attachment.pgp 

From thelema314 at gmail.com  Thu Jul  3 00:46:34 2008
From: thelema314 at gmail.com (Edgar Friendly)
Date: Wed, 02 Jul 2008 19:46:34 -0500
Subject: [Tech] Switch Repository to Git
In-Reply-To: <20080702161116.GE3513@freenetproject.org>
References: <200806300031.03920.bombe@pterodactylus.net>	<20080701040206.GB26659@freenetproject.org>	<200807011923.20243.bombe@pterodactylus.net>	<g4fcmf$pgm$1@ger.gmane.org>	<ff6a9c820807020821of39c53dnb1991530c043c42c@mail.gmail.com>	<20080702152433.GD3513@freenetproject.org>	<ff6a9c820807020834h38e1b499r9da1ccc630d6b322@mail.gmail.com>
	<20080702161116.GE3513@freenetproject.org>
Message-ID: <486C216A.8050007@gmail.com>

Florent Daigni?re wrote:
> I have no problem with you (or anybody else) using the tools they want.
> I just don't want brazillion of incompatible/forked clients to spawn up
> in the wild and to connect to the main network.

Reflecting on this idea, I think it'd be good (in the long run) if this
did happen.  Of course the network would get disrupted, but I thought
that the idea of Freenet was to have a disruption-resistant network.
And a brazillion forks means many new developers trying changes.  If the
project doesn't reject their changes, they would become a great force
for building a better Fred.

OTOH, without DSCM, forked clients will still exist, it'll just be
tougher to keep them up to date and to merge any improvements back to
the official client.

$0.02 from an oldie,

E.


From nextgens at freenetproject.org  Thu Jul  3 00:50:15 2008
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Thu, 3 Jul 2008 02:50:15 +0200
Subject: [Tech] Switch Repository to Git
In-Reply-To: <486C216A.8050007@gmail.com>
References: <200806300031.03920.bombe@pterodactylus.net>
	<20080701040206.GB26659@freenetproject.org>
	<200807011923.20243.bombe@pterodactylus.net>
	<g4fcmf$pgm$1@ger.gmane.org>
	<ff6a9c820807020821of39c53dnb1991530c043c42c@mail.gmail.com>
	<20080702152433.GD3513@freenetproject.org>
	<ff6a9c820807020834h38e1b499r9da1ccc630d6b322@mail.gmail.com>
	<20080702161116.GE3513@freenetproject.org>
	<486C216A.8050007@gmail.com>
Message-ID: <20080703005014.GB3519@freenetproject.org>

* Edgar Friendly <thelema314 at gmail.com> [2008-07-02 19:46:34]:

> Florent Daigni?re wrote:
> > I have no problem with you (or anybody else) using the tools they want.
> > I just don't want brazillion of incompatible/forked clients to spawn up
> > in the wild and to connect to the main network.
> 
> Reflecting on this idea, I think it'd be good (in the long run) if this
> did happen.  Of course the network would get disrupted, but I thought
> that the idea of Freenet was to have a disruption-resistant network.
> And a brazillion forks means many new developers trying changes.  If the
> project doesn't reject their changes, they would become a great force
> for building a better Fred.
> 
> OTOH, without DSCM, forked clients will still exist, it'll just be
> tougher to keep them up to date and to merge any improvements back to
> the official client.
> 
> $0.02 from an oldie,
> 
> E.

Heh, I'm not against the idea here; I'm just being pragmatic: we don't
have the resources to deal with forked clients.

NextGen$
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/tech/attachments/20080703/21a25ac9/attachment.pgp 

From ajft at ajft.org  Fri Jul  4 01:44:32 2008
From: ajft at ajft.org (Adrian Tritschler)
Date: Fri, 04 Jul 2008 11:44:32 +1000
Subject: [Tech] Switch Repository to Git
In-Reply-To: <20080702161116.GE3513@freenetproject.org>
References: <200806300031.03920.bombe@pterodactylus.net>
	<20080701040206.GB26659@freenetproject.org>
	<200807011923.20243.bombe@pterodactylus.net>
	<g4fcmf$pgm$1@ger.gmane.org>
	<ff6a9c820807020821of39c53dnb1991530c043c42c@mail.gmail.com>
	<20080702152433.GD3513@freenetproject.org>
	<ff6a9c820807020834h38e1b499r9da1ccc630d6b322@mail.gmail.com>
	<20080702161116.GE3513@freenetproject.org>
Message-ID: <486D8080.1000505@ajft.org>

Florent Daigni?re wrote:
> * Daniel Cheng <j16sdiz+freenet at gmail.com> [2008-07-02 23:34:29]:
> 
>> 2008/7/2 Florent Daigni?re <nextgens at freenetproject.org>:
>>> * Daniel Cheng <j16sdiz+freenet at gmail.com> [2008-07-02 23:21:45]:
>>>

...snip... discussion on SCM du jour

> Sure but why should we make it easier if it's not to encourage it then ?
> :)
> 
>>> We need the network to be homogeneous version and bug-wise to be debuggable
>>> and to move forward.
>> Anyway, you can't stop me (or anybody else) from using git-svn locally
>> (and I am using it).
>>
> 
> I have no problem with you (or anybody else) using the tools they want.
> I just don't want brazillion of incompatible/forked clients to spawn up
> in the wild and to connect to the main network.

That's a little bit like a web server developer saying they only want a 
specific web browser out there connecting "to the main network".  Or a 
XyzBSD protocol guy saying they only want XyzBSD TCP/IP implementations 
out there connecting to "the internet".

You build a distributed network, you have to make it robust for anything 
and everything connecting to it.

	Adrain

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://emu.freenetproject.org/pipermail/tech/attachments/20080704/6417ccd1/attachment.pgp 

From nextgens at freenetproject.org  Fri Jul  4 04:08:20 2008
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Fri, 4 Jul 2008 06:08:20 +0200
Subject: [Tech] Switch Repository to Git
In-Reply-To: <486D8080.1000505@ajft.org>
References: <200806300031.03920.bombe@pterodactylus.net>
	<20080701040206.GB26659@freenetproject.org>
	<200807011923.20243.bombe@pterodactylus.net>
	<g4fcmf$pgm$1@ger.gmane.org>
	<ff6a9c820807020821of39c53dnb1991530c043c42c@mail.gmail.com>
	<20080702152433.GD3513@freenetproject.org>
	<ff6a9c820807020834h38e1b499r9da1ccc630d6b322@mail.gmail.com>
	<20080702161116.GE3513@freenetproject.org>
	<486D8080.1000505@ajft.org>
Message-ID: <20080704040818.GA3521@freenetproject.org>

* Adrian Tritschler <ajft at ajft.org> [2008-07-04 11:44:32]:

> Florent Daigni?re wrote:
>> * Daniel Cheng <j16sdiz+freenet at gmail.com> [2008-07-02 23:34:29]:
>>
>>> 2008/7/2 Florent Daigni?re <nextgens at freenetproject.org>:
>>>> * Daniel Cheng <j16sdiz+freenet at gmail.com> [2008-07-02 23:21:45]:
>>>>
>
> ...snip... discussion on SCM du jour
>

That's *the* topic of this thread.

>> Sure but why should we make it easier if it's not to encourage it then ?
>> :)
>>
>>>> We need the network to be homogeneous version and bug-wise to be debuggable
>>>> and to move forward.
>>> Anyway, you can't stop me (or anybody else) from using git-svn locally
>>> (and I am using it).
>>>
>>
>> I have no problem with you (or anybody else) using the tools they want.
>> I just don't want brazillion of incompatible/forked clients to spawn up
>> in the wild and to connect to the main network.
>
> That's a little bit like a web server developer saying they only want a  
> specific web browser out there connecting "to the main network".

Except that web-technologies are specified and not in constant
evolution. Freenet's inter-node protocol is not specified yet and that's
on purpose.

> Or a XyzBSD protocol guy saying they only want XyzBSD TCP/IP implementations  
> out there connecting to "the internet".
>

What's your problem exactly? I can always say that I don't *want* other
implementations; that won't prevent them from appearing... and I am
aware of that. 

The standard corporate response to that kind of concerns is to make
every new version of the official client incompatible with previous.

The original debate was about "why should we switch to git": I have just
explained why I don't receive the "makes branching/forking easier" as an
important point for now.

> You build a distributed network, you have to make it robust for anything  
> and everything connecting to it.
>

I'm fed up with people telling me what I have to do.

If you can't understand that we have only a limited amount of
resources and time, well... it's not even worth arguing.

For your information, "robust for anything and everything" doesn't exist.

NextGen$
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/tech/attachments/20080704/31a549b4/attachment.pgp 

From thelema314 at gmail.com  Fri Jul  4 17:46:01 2008
From: thelema314 at gmail.com (Edgar Friendly)
Date: Fri, 04 Jul 2008 12:46:01 -0500
Subject: [Tech] Switch Repository to Git
In-Reply-To: <20080704040818.GA3521@freenetproject.org>
References: <200806300031.03920.bombe@pterodactylus.net>	<20080701040206.GB26659@freenetproject.org>	<200807011923.20243.bombe@pterodactylus.net>	<g4fcmf$pgm$1@ger.gmane.org>	<ff6a9c820807020821of39c53dnb1991530c043c42c@mail.gmail.com>	<20080702152433.GD3513@freenetproject.org>	<ff6a9c820807020834h38e1b499r9da1ccc630d6b322@mail.gmail.com>	<20080702161116.GE3513@freenetproject.org>	<486D8080.1000505@ajft.org>
	<20080704040818.GA3521@freenetproject.org>
Message-ID: <486E61D9.7060304@gmail.com>

Florent Daigni?re wrote:
> The original debate was about "why should we switch to git": I have just
> explained why I don't receive the "makes branching/forking easier" as an
> important point for now.
> 
And I'd like to chime in that easier branching/forking doesn't mean only
more incompatible clients, it also means a different type of interaction
with your SCM, where checking in happens nearly as often as saving your
work.  This may have positive effects on development because the more
history is kept in the SCM, the easier it is to revert to a previous
version on failure, or pull from somewhere else in the tree of code if
you realize you didn't want to get rid of something.

A single line of development results in less of this because people
generally commit to the SCM only top-quality, fully working and tested
code, so more of the work happens outside the SCM, losing the above
benefits to some extent.

E.


From toad at amphibian.dyndns.org  Fri Jul  4 22:00:11 2008
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Fri, 4 Jul 2008 23:00:11 +0100
Subject: [Tech] Switch Repository to Git
In-Reply-To: <20080703005014.GB3519@freenetproject.org>
References: <200806300031.03920.bombe@pterodactylus.net>
	<486C216A.8050007@gmail.com>
	<20080703005014.GB3519@freenetproject.org>
Message-ID: <200807042300.11475.toad@amphibian.dyndns.org>

On Thursday 03 July 2008 01:50, Florent Daigni?re wrote:
> * Edgar Friendly <thelema314 at gmail.com> [2008-07-02 19:46:34]:
> 
> > Florent Daigni?re wrote:
> > > I have no problem with you (or anybody else) using the tools they want.
> > > I just don't want brazillion of incompatible/forked clients to spawn up
> > > in the wild and to connect to the main network.
> > 
> > Reflecting on this idea, I think it'd be good (in the long run) if this
> > did happen.  Of course the network would get disrupted, but I thought
> > that the idea of Freenet was to have a disruption-resistant network.
> > And a brazillion forks means many new developers trying changes.  If the
> > project doesn't reject their changes, they would become a great force
> > for building a better Fred.
> > 
> > OTOH, without DSCM, forked clients will still exist, it'll just be
> > tougher to keep them up to date and to merge any improvements back to
> > the official client.
> > 
> > $0.02 from an oldie,
> > 
> > E.
> 
> Heh, I'm not against the idea here; I'm just being pragmatic: we don't
> have the resources to deal with forked clients.

It's an emergent system, 100 clients each with slightly different behaviour 
will kill it.
> 
> NextGen$
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://emu.freenetproject.org/pipermail/tech/attachments/20080704/a9d6880c/attachment.pgp 

From nextgens at freenetproject.org  Sat Jul  5 01:16:52 2008
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Sat, 5 Jul 2008 03:16:52 +0200
Subject: [Tech] Switch Repository to Git
In-Reply-To: <486E61D9.7060304@gmail.com>
References: <20080701040206.GB26659@freenetproject.org>
	<200807011923.20243.bombe@pterodactylus.net>
	<g4fcmf$pgm$1@ger.gmane.org>
	<ff6a9c820807020821of39c53dnb1991530c043c42c@mail.gmail.com>
	<20080702152433.GD3513@freenetproject.org>
	<ff6a9c820807020834h38e1b499r9da1ccc630d6b322@mail.gmail.com>
	<20080702161116.GE3513@freenetproject.org>
	<486D8080.1000505@ajft.org>
	<20080704040818.GA3521@freenetproject.org>
	<486E61D9.7060304@gmail.com>
Message-ID: <20080705011650.GA3525@freenetproject.org>

* Edgar Friendly <thelema314 at gmail.com> [2008-07-04 12:46:01]:

> Florent Daigni?re wrote:
> > The original debate was about "why should we switch to git": I have just
> > explained why I don't receive the "makes branching/forking easier" as an
> > important point for now.
> > 
> And I'd like to chime in that easier branching/forking doesn't mean only
> more incompatible clients, it also means a different type of interaction
> with your SCM, where checking in happens nearly as often as saving your
> work.  This may have positive effects on development because the more
> history is kept in the SCM, the easier it is to revert to a previous
> version on failure, or pull from somewhere else in the tree of code if
> you realize you didn't want to get rid of something.
> 

Two points here:
	1) if we ever use a DSCM it *will* be in a centralized manner:
	there will be a public tree devs will have to push to; I do not
	think that the full history of each dev's individual
	"working-copy" will be pushed there.
	2) How the SCM is used depends on people more than the tools;
	see below

> A single line of development results in less of this because people
> generally commit to the SCM only top-quality, fully working and tested
> code,

Do you read the commits diffs?
That's for sure, we only commit top-quality, fully working and tested
code... and that's why we don't need a bug-tracker and we have released
freenet 1.0 since years now ;)

> so more of the work happens outside the SCM, losing the above
> benefits to some extent.
> 

As said previously it depends more on people than on the tools you use;
Say we switch to git tomorrow... someone is willing to work on a new
feature or a bugfix... he will create a branch locally... work on it...
probably do some stupid mistakes (as we all do)... and when he has
something working he will push that back to the official trunk. At that
moment he will be given the choice in between "merging incrementally"
and "merging fully". The choice is still up to him and I bet that people
not committing often right now won't merge incrementally their work
either. Experience has shown that long-standing coders are *not*
numerous; if we ever have to look for the history of the merge, it will
be present only on the dev's working copy who is likely to have
disappeared since a while.

NextGen$
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/tech/attachments/20080705/becf1df1/attachment.pgp 

From thelema314 at gmail.com  Mon Jul  7 11:52:44 2008
From: thelema314 at gmail.com (Edgar Friendly)
Date: Mon, 07 Jul 2008 06:52:44 -0500
Subject: [Tech] Switch Repository to Git
In-Reply-To: <20080705011650.GA3525@freenetproject.org>
References: <20080701040206.GB26659@freenetproject.org>	<200807011923.20243.bombe@pterodactylus.net>	<g4fcmf$pgm$1@ger.gmane.org>	<ff6a9c820807020821of39c53dnb1991530c043c42c@mail.gmail.com>	<20080702152433.GD3513@freenetproject.org>	<ff6a9c820807020834h38e1b499r9da1ccc630d6b322@mail.gmail.com>	<20080702161116.GE3513@freenetproject.org>	<486D8080.1000505@ajft.org>	<20080704040818.GA3521@freenetproject.org>	<486E61D9.7060304@gmail.com>
	<20080705011650.GA3525@freenetproject.org>
Message-ID: <4872038C.5030303@gmail.com>

Florent Daigni?re wrote:
> Two points here:
> 	1) if we ever use a DSCM it *will* be in a centralized manner:
> 	there will be a public tree devs will have to push to; I do not
> 	think that the full history of each dev's individual
> 	"working-copy" will be pushed there.
I expect any branches that multiple devs work on will end up in the
central server.
> 	2) How the SCM is used depends on people more than the tools;
> 	see below
The tools influence how people use them.

> 
> As said previously it depends more on people than on the tools you use;
> Say we switch to git tomorrow... someone is willing to work on a new
> feature or a bugfix... he will create a branch locally... work on it...
> probably do some stupid mistakes (as we all do)... and when he has
> something working he will push that back to the official trunk. At that
> moment he will be given the choice in between "merging incrementally"
> and "merging fully". The choice is still up to him and I bet that people
> not committing often right now won't merge incrementally their work
> either. Experience has shown that long-standing coders are *not*
> numerous; if we ever have to look for the history of the merge, it will
> be present only on the dev's working copy who is likely to have
> disappeared since a while.
> 
> NextGen$
> 
With git, both can exist - the full branch with all changes (in a
developer-specific branch name) and the "fully merged" code in the trunk.

E.


From nextgens at freenetproject.org  Mon Jul  7 12:33:09 2008
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Mon, 7 Jul 2008 14:33:09 +0200
Subject: [Tech] Switch Repository to Git
In-Reply-To: <4872038C.5030303@gmail.com>
References: <g4fcmf$pgm$1@ger.gmane.org>
	<ff6a9c820807020821of39c53dnb1991530c043c42c@mail.gmail.com>
	<20080702152433.GD3513@freenetproject.org>
	<ff6a9c820807020834h38e1b499r9da1ccc630d6b322@mail.gmail.com>
	<20080702161116.GE3513@freenetproject.org>
	<486D8080.1000505@ajft.org>
	<20080704040818.GA3521@freenetproject.org>
	<486E61D9.7060304@gmail.com>
	<20080705011650.GA3525@freenetproject.org>
	<4872038C.5030303@gmail.com>
Message-ID: <20080707123308.GC3534@freenetproject.org>

* Edgar Friendly <thelema314 at gmail.com> [2008-07-07 06:52:44]:

> Florent Daigni?re wrote:
> > Two points here:
> > 	1) if we ever use a DSCM it *will* be in a centralized manner:
> > 	there will be a public tree devs will have to push to; I do not
> > 	think that the full history of each dev's individual
> > 	"working-copy" will be pushed there.
> I expect any branches that multiple devs work on will end up in the
> central server.

...
Read the commits and you will realize that *all* our branches have been
a one-man-at-a-time job so far.

> > 	2) How the SCM is used depends on people more than the tools;
> > 	see below
> The tools influence how people use them.
> 

Sure they do but that's not my point here.

> > 
> > As said previously it depends more on people than on the tools you use;
> > Say we switch to git tomorrow... someone is willing to work on a new
> > feature or a bugfix... he will create a branch locally... work on it...
> > probably do some stupid mistakes (as we all do)... and when he has
> > something working he will push that back to the official trunk. At that
> > moment he will be given the choice in between "merging incrementally"
> > and "merging fully". The choice is still up to him and I bet that people
> > not committing often right now won't merge incrementally their work
> > either. Experience has shown that long-standing coders are *not*
> > numerous; if we ever have to look for the history of the merge, it will
> > be present only on the dev's working copy who is likely to have
> > disappeared since a while.
> > 
> > NextGen$
> > 
> With git, both can exist - the full branch with all changes (in a
> developer-specific branch name) and the "fully merged" code in the trunk.
> 

I am not saying that they can't. I am saying that developper's behaviour
won't change: they will "fully merge" even if we switch to git.

NextGen$
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/tech/attachments/20080707/41007693/attachment.pgp