Deploying from a specific path with a Git repo

[Henry]

Greetings,

I have a Git repo that contains a few small sinatra apps. So I would
like to deploy them one at at time. So I need to set a path within
the repo to deploy, but I can't figure out how to do it. This is what
I've tried:

set :repository, "g...@github.com:me/myrepo.git/app1"

But that doesn't work. Any suggestions?

Thanks!

[Jamis Buck]

Does does not let you check out a just subdirectory of a repository. If
you want to deploy just a subdirectory, you'll need to write your own
tasks that check out the repo locally, and then bundle up the
subdirectory you wish to deploy.

Git best-practice is to use one repository for one project.

- Jamis

[Henry]

Thanks for the reply. I understand the best practice of 1 repo == 1
project. But sometimes it just doesn't make sense. For example, I
have another big rails app that is not ready for deployment yet, but
I'd like to display a semi-functional splash site that uses lots of
the same assets. So I have a one-file sinatra app sitting in another
directory in the repo rather than creating another repo with duplicate
files for this purpose. It would be nice in this case just to deploy
that dir (which could have it's own teensy Capfile).

Further complicating things is the fact that you can indeed check out
paths of submodules, which seems like it doesn't fit with the 1 repo
== 1 project philosophy.

But this is not a git discussion board so I'll leave it that, except
to say thanks for Cap, it's a fantastic tool.

[David Masover]

On Thu, Jan 15, 2009 at 11:44 AM, Henry <hpo...@gmail.com> wrote:

...I have another big rails app that is not ready for deployment yet, but

I'd like to display a semi-functional splash site that uses lots of
the same assets.  So I have a one-file sinatra app sitting in another
directory in the repo rather than creating another repo with duplicate
files for this purpose.

I realize that is the easier way of doing it, but I wouldn't call it a best practice.

On the last major project I had, we had our own from-scratch-and-plugins Rails app, and a Mephisto implementation, a Spree implementation, and a Castronaut implementation.

We did two things:

First, we did actually duplicate the files between them, when necessary. In this case, the original Rails app was on SVN, and everything else was on Git.

Second, we used a separate "asset server" -- really the same machine, but it could be anything, and we were considering doing that with Amazon S3. So we built a separate project which was just the assets, and wrote a deploy task that just ran deploy:update_code and deploy:symlink -- then configured nginx to serve files directly from there, statically.

Bonus: Browser caching works, now, since the two apps will be pointing to the same URLs, not just copies of the same file.

And finally, for the things which were too hard to do that with, or which we simply didn't want to bother changing yet -- for example, a common layout file -- we put that in its own repository, and used submodules.

I don't know how well this maps onto the default tasks, though. I remember writing a lot of my own -- probably more than I needed to, but enough that I'm sure if I wanted to do what you're suggesting, I could have pretty easily.

Further complicating things is the fact that you can indeed check out
paths of submodules, which seems like it doesn't fit with the 1 repo
== 1 project philosophy.

Well, a submodule is sort of an alternative to using symlinks. I think it does make sense that it's possible to map a subdirectory to a subdirectory -- you might not need the entire other project, or your project might be extremely sensitive to directory structure.

[Wincent Colaiuta]

On 15 ene, 18:44, Henry <hpoy...@gmail.com> wrote:
> Thanks for the reply.  I understand the best practice of 1 repo == 1
> project.   But sometimes it just doesn't make sense.  For example, I
> have another big rails app that is not ready for deployment yet, but
> I'd like to display a semi-functional splash site that uses lots of
> the same assets.  So I have a one-file sinatra app sitting in another
> directory in the repo rather than creating another repo with duplicate
> files for this purpose.  It would be nice in this case just to deploy
> that dir (which could have it's own teensy Capfile).

Seeing as you have two versions of the same thing, sounds like a job
for branches: "master" for the Rails implementation, in development;
and "sinatra" for the placeholder.

At least, that's the way I would do it.

If they weren't two versions of the same thing but actually two
different apps then I would do what Jamis says and have two repos.

Wincent