Since it seems that everyone is ok with git I will move the DWT2 repository to github. That leads to the next question: Would git submodules be a good idea? I haven't use submodules myself my it sounds good in theory. I'm thinking about having sub repository for basically every top level directory in the current repository. One repsository for jface, one for dwt-win, one for dwt-linux and so on. What do you think?


-- 
/Jacob Carlborg

On 15.08.2011 19:26, Jacob Carlborg wrote:
> Since it seems that everyone is ok with git I will move the DWT2
> repository to github. That leads to the next question: Would git
> submodules be a good idea? I haven't use submodules myself my it sounds
> good in theory. I'm thinking about having sub repository for basically
> every top level directory in the current repository. One repsository for
> jface, one for dwt-win, one for dwt-linux and so on. What do you think?
>
>
If it simplifies things instead of complicating them, sure.  I have no experience with neither submodules nor the Mercurial subrepos.  I hope that hg-git supports them, but wasn't able to find a repository for testing.

On Mon, 15 Aug 2011 19:26:57 +0200, Jacob Carlborg wrote:

> Since it seems that everyone is ok with git I will move the DWT2 repository to github. That leads to the next question: Would git submodules be a good idea? I haven't use submodules myself my it sounds good in theory. I'm thinking about having sub repository for basically every top level directory in the current repository. One repsository for jface, one for dwt-win, one for dwt-linux and so on. What do you think?

My experience with submodules has been great. There is a little bit of overhead which I'll explain below, but cloning just becomes

$ git clone url
$ git submodule init
$ git submodule update

(I of course don't know hg-git's support for this)

I'd recommend separate repositories, I guess it isn't feasible to support all the OS specific stuff under one source base? I'd think that would be easier than supporting D1/D2/Phobos/Tango in one source tree.

But do you really need submodules? If you want dwt you'll either pull in dtw-win dwt-linux as a submodule of your own or just dwt-linux and jface.

Personally I think the OS's should be brought together and the library/ language separation should be their own repos (jface its own repo). In fact if that sounds reasonable I'll volunteer to try and make it happen (as you've done dwt-mac you might know this is a bad idea)?

Back to submodules. These create clones of a completely different repo in a subdirectory of the project. The commit hash is stored in the parent, not the files. You can commit/branch/push/pull/merge in your submodules just like any other local repository. As long as your working directory is within the submodule directory.

The .gitsubmodules config file is tracked in the repository just like any other file. This file stores the information about the repository locations and directories to use. The first time setup can be done from the command line but say for example someone forks dwt-linux and jface.

Assuming we are using a Hub project (or whatever the formal name would be). There is DWT which has submodules of jface, dwt-linux... If the user wants to have their own for of DWT that points to their forks of jface... they would need edit the .gitsubmodules so that the URL locations point to their git repositories.

$ git submodule init just takes the information found in the configuration file and moves them into .git/config So once the .gitsubmodules is updated you'll have easy checkout.

I don't think a Hub project is needed.

On 2011-08-16 03:37, Jesse Phillips wrote:
> On Mon, 15 Aug 2011 19:26:57 +0200, Jacob Carlborg wrote:
>
>> Since it seems that everyone is ok with git I will move the DWT2
>> repository to github. That leads to the next question: Would git
>> submodules be a good idea? I haven't use submodules myself my it sounds
>> good in theory. I'm thinking about having sub repository for basically
>> every top level directory in the current repository. One repsository for
>> jface, one for dwt-win, one for dwt-linux and so on. What do you think?
>
> My experience with submodules has been great. There is a little bit of
> overhead which I'll explain below, but cloning just becomes
>
> $ git clone url
> $ git submodule init
> $ git submodule update
>
> (I of course don't know hg-git's support for this)
>
> I'd recommend separate repositories, I guess it isn't feasible to support
> all the OS specific stuff under one source base? I'd think that would be
> easier than supporting D1/D2/Phobos/Tango in one source tree.

I'm not exactly sure what you mean with "one source base", because currently all OS specific stuff are in one repository.

> But do you really need submodules? If you want dwt you'll either pull in
> dtw-win dwt-linux as a submodule of your own or just dwt-linux and jface.

The problem is that you also always need the "base" repository. Which contains implementations of the some Java classes and other utility functions used by dwt.

> Personally I think the OS's should be brought together and the library/
> language separation should be their own repos (jface its own repo). In
> fact if that sounds reasonable I'll volunteer to try and make it happen
> (as you've done dwt-mac you might know this is a bad idea)?

Currently everything is in one repository but it's in separate top level directories. Having all the OS's merge in the same directory would be very very bad. First, it's just too much code for that. Second it's not how SWT is arranged and it would be very difficult to port future versions of SWT.

That was why I thought submodules could take the best of both approaches, that is, one repository for everything (like we have now) versus individual repositories for each project.

> Back to submodules. These create clones of a completely different repo in
> a subdirectory of the project. The commit hash is stored in the parent,
> not the files. You can commit/branch/push/pull/merge in your submodules
> just like any other local repository. As long as your working directory
> is within the submodule directory.
>
> The .gitsubmodules config file is tracked in the repository just like any
> other file. This file stores the information about the repository
> locations and directories to use. The first time setup can be done from
> the command line but say for example someone forks dwt-linux and jface.
>
> Assuming we are using a Hub project (or whatever the formal name would
> be). There is DWT which has submodules of jface, dwt-linux... If the user
> wants to have their own for of DWT that points to their forks of jface...
> they would need edit the .gitsubmodules so that the URL locations point
> to their git repositories.
>
> $ git submodule init just takes the information found in the
> configuration file and moves them into .git/config So once
> the .gitsubmodules is updated you'll have easy checkout.
>
> I don't think a Hub project is needed.

I think I need to read more about submodules. What I was hoping for was that you could have individual repositories for each project and then a super project. When the super project could contain the build script and when it's cloned the sub respiratory will be cloned as well.

-- 
/Jacob Carlborg

On Tue, 16 Aug 2011 08:54:16 +0200, Jacob Carlborg wrote:

> I'm not exactly sure what you mean with "one source base", because currently all OS specific stuff are in one repository.
> 
>> But do you really need submodules? If you want dwt you'll either pull in dtw-win dwt-linux as a submodule of your own or just dwt-linux and jface.
> 
> The problem is that you also always need the "base" repository. Which contains implementations of the some Java classes and other utility functions used by dwt.

Oh, that makes sense then yeah submodules is not a bad approach.

>> Personally I think the OS's should be brought together and the library/ language separation should be their own repos (jface its own repo). In fact if that sounds reasonable I'll volunteer to try and make it happen (as you've done dwt-mac you might know this is a bad idea)?
> 
> Currently everything is in one repository but it's in separate top level directories. Having all the OS's merge in the same directory would be very very bad. First, it's just too much code for that. Second it's not how SWT is arranged and it would be very difficult to port future versions of SWT.
> 
> That was why I thought submodules could take the best of both approaches, that is, one repository for everything (like we have now) versus individual repositories for each project.
> 
> I think I need to read more about submodules. What I was hoping for was that you could have individual repositories for each project and then a super project. When the super project could contain the build script and when it's cloned the sub respiratory will be cloned as well.

It is almost like that. It's just that the cloning also requires the initialization and cloning of the submodules. You'll have to keep them in sync and I've never submoduled a project that had submodules it self.

I'm not user if there is much point in separating them if you can use dwt- linux or win in something else. But jface could be its own repository as that isn't required to used DWT at all. And making that a submodule is fine.

On 2011-08-16 16:30, Jesse Phillips wrote:
> It is almost like that. It's just that the cloning also requires the
> initialization and cloning of the submodules. You'll have to keep them in
> sync and I've never submoduled a project that had submodules it self.

Yeah, I've read that now.

> I'm not user if there is much point in separating them if you can use dwt-
> linux or win in something else. But jface could be its own repository as
> that isn't required to used DWT at all. And making that a submodule is
> fine.

Not all top level directories need to be submodules, that was just a thought. I could include everything to make it possible to build DWT in one repository (the super repository) and have everything else in submodules.

-- 
/Jacob Carlborg

On Tue, 16 Aug 2011 18:46:28 +0200, Jacob Carlborg wrote:

> Not all top level directories need to be submodules, that was just a thought. I could include everything to make it possible to build DWT in one repository (the super repository) and have everything else in submodules.

Looking a little closer at the stuff, I've remembered part of DWT is a port of Java, and looks like part of Eclipse.

My thought would be that those are separate porting efforts, and you'd have dwt (which includes the the Windows and Linux code together, ie the swt source) which has the Java/Eclipse ports as submodules.

Though it seems that DWT isn't laid out the same as SWT 3.8's repo: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/

Anyway, I hope I'm contributing to you making a decision rather than just adding confusion.

On 2011-08-17 03:36, Jesse Phillips wrote:
> On Tue, 16 Aug 2011 18:46:28 +0200, Jacob Carlborg wrote:
>
>> Not all top level directories need to be submodules, that was just a
>> thought. I could include everything to make it possible to build DWT in
>> one repository (the super repository) and have everything else in
>> submodules.
>
> Looking a little closer at the stuff, I've remembered part of DWT is a
> port of Java, and looks like part of Eclipse.

DWT is a port of SWT which is Java and part of Eclipse. To ease the porting some parts of Java is ported as well.

> My thought would be that those are separate porting efforts, and you'd
> have dwt (which includes the the Windows and Linux code together, ie the
> swt source) which has the Java/Eclipse ports as submodules.

Ok.

> Though it seems that DWT isn't laid out the same as SWT 3.8's repo:
> http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/

I have no idea of SWT 3.8 is laid out. DWT is quite far behind and is a port of SWT 3.4.

> Anyway, I hope I'm contributing to you making a decision rather than just
> adding confusion.

No no, you're helping :)

-- 
/Jacob Carlborg

On 16.08.2011 18:46, Jacob Carlborg wrote:
> On 2011-08-16 16:30, Jesse Phillips wrote:
>>  It is almost like that. It's just that the cloning also requires the
>>  initialization and cloning of the submodules. You'll have to keep them in
>>  sync and I've never submoduled a project that had submodules it self.
>
> Yeah, I've read that now.
>
>>  I'm not user if there is much point in separating them if you can use dwt-
>>  linux or win in something else. But jface could be its own repository as
>>  that isn't required to used DWT at all. And making that a submodule is
>>  fine.
>
> Not all top level directories need to be submodules, that was just a
> thought. I could include everything to make it possible to build DWT in
> one repository (the super repository) and have everything else in
> submodules.
>

What problem is splitting things into submodules supposed to solve?  The current Mercurial repository with everything in it is just 50 MB.  I suppose Git repositories take up more space, but assume that's not why you want to split things up?

If submodules are meant for the same use cases as SVN externals, they are primarily for automatically pulling in stuff that is separate because it is actually a separate project, probably maintained by someone else, or maybe just hosted elsewhere for some reason.  Not for splitting a project into parts.  Which is why I'm wondering what exactly you want to achieve here.

On Wed, 17 Aug 2011 11:46:23 +0200, torhu wrote:

> If submodules are meant for the same use cases as SVN externals, they are primarily for automatically pulling in stuff that is separate because it is actually a separate project, probably maintained by someone else, or maybe just hosted elsewhere for some reason.  Not for splitting a project into parts.  Which is why I'm wondering what exactly you want to achieve here.

With SVN you will create large projects/multi-projects in one repository, this can include multiple tools, libraries, and everything else. SVN also provides the ability to checkout subdirectories without pulling everything else.

My suggest for submoduling is to separate parts that could be reused by something not DWT. For example the base directory that contains base Java components. The parts of Eclipse that aren't part of SWT (as it is handled by the SWT repository). These can be used by others that are porting something from Java/Eclipse that isn't DWT. (not likely but still different).