Re: [git-users] Subdirectories and Continuous Integration

[Thomas Ferris Nicolaisen]

Hi Sean, welcome to the group!

I'm afraid I wasn't clear enough in my statement. I meant to split up the 
projects, as per CruiseControl configuration - not necessarily split the 
source repository.

It could very well be that it's best to keep the source of the different 
apps in the same repository, or workspace. But the poster says "We treat 
each app as 
its own project and would like to map that into CruiseControl". My point is 
that if this is hard to do, perhaps they are better off switching 
CruiseControl for something else, like Jenkins, Hudson, TeamCity or Bamboo.

I disagree with you on this one though:

>
On Sunday, May 29, 2011 4:03:42 AM UTC+2, Sean Roehnelt wrote:
>
>
> ... Git lacks good support for managing large source trees due to not 
> supporting push/pull of specific repo sub-directories. My experience with 
> Git shows it was created for a different set of objectives than most 
> software project need to solve or are even relevant while adding a large 
> amount of complexity to simple time proven methodologies like continuous 
> integration.
>

I find it a bit misleading that you say "most software projects". 

You're right in that Git does not work on hierarchical data repositories of 
arbitrary sizes (infinite depth). For example, if you have a global website 
with web-pages for hundreds of subdivisions, each of which have their own 
subdivisions, keeping it all in one Git repository would probably be a bad 
idea, SVN would probably be a better option. 

Now I don't think that "most projects" have this requirement. In most 
projects I've seen, I check out the whole code, not some arbitrary sub-tree.

That said, Git scales really well on large repositories (the linux kernel is 
a good enough example with 14 MLOCs).

Its features are practical on every software project I've seen, from tiny 
open source project, to big enterprisey projects.

And it works really fine with continuous integration. Quoting the lead coder 
on Jenkins : 
JenkinsCI + Git = <3

I totally agree with you on that the decision of when to split out parts of 
a Git repository is a big "It depends" question, impossible for us to answer 
with so little context.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Re: [git-users] Subdirectories and Continuous Integration

[Sean Roehnelt]

Finding this post via google prompted me to join this group...

On Sunday, April 3, 2011 6:33:14 AM UTC-7, Thomas Ferris Nicolaisen wrote:
>
> I would go for splitting them into 7 isolated projects. In my experience, 
> the advantages of this isolation greatly outweighs advantages of keeping 
> them in one place, regardless of what SCM you are using.


I would like to insert a huge "that depends..." about this recommendation. 
Depending on your projects, their shared resources, other factors; 7 
isolated projects "may" be a good move if you actually have 7 separate 
initiatives (i.e. only one moving target), but it could create more, 
artificial, problems as well. My advise would be to use a single repo for 
all resources of a project that are moving targets and it's really how you 
look at or source code... Do you have 7 separate projects each with their 
own schedule and dependencies or one project with 7 components being worked 
on simultaneously?

If the former, you probably already want to break them apart into separate 
repo's and this might be a good opportunity to
 break them apart. If the later, Git lacks good support for managing large 
source trees due to not supporting push/pull of specific repo 
sub-directories. My experience with Git shows it was created for a different 
set of objectives than most software project need to solve or are even 
relevant while adding a large amount of complexity to simple time proven 
methodologies like continuous integration.

If me or anybody else breaks something in the code, it should break the 
build and your auto build server should tell you about it when it happens, 
and the team needs to fix it inline when it happens and the code changes are 
fresh in people's heads... not 3 months later in some sort of integration 
effort.

You want CruiseControl to build the 7 different apps as 7 different 
> projects. If this is problematic, I think switching to Git is not the first 
> thing you should address in your organization ;)
>

... that really all depends on many factors and I wouldn't jump to any such 
conclusion about it... 

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Re: [git-users] Subdirectories and Continuous Integration

[Thomas Ferris Nicolaisen]

I would go for splitting them into 7 isolated projects. In my experience, 
the advantages of this isolation greatly outweighs advantages of keeping 
them in one place, regardless of what SCM you are using.

You want CruiseControl to build the 7 different apps as 7 different 
projects. If this is problematic, I think switching to Git is not the first 
thing you should address in your organization ;)

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Re: [git-users] Subdirectories and Continuous Integration

[Jeremiah Dodds]

On Fri, Apr 1, 2011 at 2:54 PM, Barry  wrote:

> Hello everyone,
>
> We just started using git, and have an issue with our continuous
> integration builds.  We use CruiseControl, and have one git repository
> that consists of many applications that are individually built.  Right
> now, when any change is made to a branch all applications that are
> building in CruiseControl are built and the modification list contains
> all changes for the branch.  The behavior that we are used to is if a
> change is made in an application, CruiseControl will only build that
> application (not all apps from that branch) and report only the
> modifications to that app (not all changes on the branch).  Is it
> possible to do this with git?
>
> Our repo essentially looks like:
> Basedir/app1
>/app2
>/app3
>/internal/app4
>/internal/app5
>/partner/external/app6
>/partner/external/app7
>
> So we have a number of applications that make up our repository, but
> they are not all at the same directory level.  And our CruiseControl
> will build app1, app2, app3, app4, and so on.  We treat each app as
> its own project and would like to map that into CruiseControl so that
> a change in app2 will only build app2 and not show modifications that
> were made in app4.
>
> Thanks for taking the time to read this and for any help you may be
> able to provide,
> Barry
>
>
I'm not familiar with setting up CruiseControl, but in general the svn-style
organization of "one repo with subdirs for projects"  doesn't work too well
with git -- to put it simply, git doesn't care about directories, and svn
only cares about directories.

Your apps can live in separate repositories and make use of submodules
(kinda like svn:external). It's a bit more setup, and it might be hard to do
so as a "big transition at once" type of thing, but I highly doubt that
you'll want to keep the central-repo layout as you go forward.

You should note that I am speaking from ignorance here -- I've never been a
fan of the single repo anyhow, and I haven't tried, nor would I try to use
git like that. Someone else who knows more about that than I might come in
and actually give you advice as to your desired setup, or just getting
CruiseControl to play nice with it.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

[git-users] Subdirectories and Continuous Integration

[Barry]

Hello everyone,

We just started using git, and have an issue with our continuous
integration builds.  We use CruiseControl, and have one git repository
that consists of many applications that are individually built.  Right
now, when any change is made to a branch all applications that are
building in CruiseControl are built and the modification list contains
all changes for the branch.  The behavior that we are used to is if a
change is made in an application, CruiseControl will only build that
application (not all apps from that branch) and report only the
modifications to that app (not all changes on the branch).  Is it
possible to do this with git?

Our repo essentially looks like:
Basedir/app1
/app2
/app3
/internal/app4
/internal/app5
/partner/external/app6
/partner/external/app7

So we have a number of applications that make up our repository, but
they are not all at the same directory level.  And our CruiseControl
will build app1, app2, app3, app4, and so on.  We treat each app as
its own project and would like to map that into CruiseControl so that
a change in app2 will only build app2 and not show modifications that
were made in app4.

Thanks for taking the time to read this and for any help you may be
able to provide,
Barry

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.