Newbie question - multiple head prevention

[Michael Diamond]

The images aren't sitting on the source server, are they?  I thought your
designers were putting images on the production server.  So does that mean
the source server is pulling / the production server is pushing back to the
source server?  That seems like a poor security model.  I'd want to lock any
private servers from getting any kind of data* from a public server, least
of all the source server.

If not having an images repo doesn't make sense, then I'd definitely
encourage using multiple repositories.  It's one of Mercurial's great
features that it's so easy to create multiple repositories, and one for
source and one for image binaries has several advantages, not the least of
which is it will keep your source repository faster and lighter, since
developers don't need to work with a repository full of binary commits and
filter through those to find the ones they actually care about.

Michael Diamond
dimo414 at gmail.com
mdiamond at willamette.edu
http://www.DigitalGemstones.com


On Tue, Jun 8, 2010 at 10:40 AM, Tony Zakula <tonyzakula at gmail.com> wrote:

> Thank you for the thoughts.  I have ignored things like product
> images.  This particular system allows the designers to edit pieces of
> the layout using html and it is stored in the database.  However, when
> they run into issues or wants, and they need something in the JSP code
> changed, the developer has to do it and sometimes it is needed to have
> the images for the page layout sake to visually see everything.  I
> guess I could have the developer pull the images, but then I need to
> setup webdav or something like that.  Right now, there isn't a way to
> get files in and out except with hg or ssh.
>
> So maybe number two would be better?  Except I have one big repo right now.
>  :-)
>
> On Tue, Jun 8, 2010 at 12:31 PM, Michael Diamond <dimo414 at gmail.com>
> wrote:
> > Tony,
> >
> > I would be inclined to make these two separate repositories.  You're
> looking
> > at two almost completely unrelated workflows, and I would be inclined to
> > either:
> > 1. Just .hgignore the image directory - this may not be acceptable for
> your
> > use case, but I find just keeping backups of the site makes more sense
> for
> > binary files like images than checking them into a repository.
> > 2. .hgignore the image directory and create a repo in that directory
> which
> > gets committed and updated by the web interface, and which the developers
> > don't need to be concerned about, but can pull when they need to.
> >
> > I'd be fairly surprised if you really got a lot of benefit from version
> > tracking images, so in my mind #1 makes the most sense.
> >
> > Michael Diamond
> > dimo414 at gmail.com
> > mdiamond at willamette.edu
> > http://www.DigitalGemstones.com
> >
> >
> > On Tue, Jun 8, 2010 at 8:12 AM, Tony Zakula <tonyzakula at gmail.com>
> wrote:
> >>
> >> Hi,
> >>
> >> I have a source server setup with the webcgi for multiple repos.
> >> Everything is working well.  I would like to prevent multiple heads on
> >> the production web server and I suppose the source server, but I am
> >> just slightly confused. :-)
> >>
> >> The production web server has hg installed.  It pulls updates from the
> >> source server.  Developers pull and push changes to the source server.
> >>  However, designers upload images through a web interface to a
> >> designated directory on the production web server.  I need to push
> >> those changes(images) to the source control server.  I can do that,
> >> but I would like to prevent multiple heads being created.  So do I
> >> install the hook only on the source server?  Does anyone have any
> >> wisdom they can share?  The developers are using Netbeans, but on the
> >> web server and source server, we are only using the command line and
> >> no gui as it is a headless server.
> >>
> >> Thanks,
> >>
> >> Tony Z
> >> _______________________________________________
> >> Mercurial mailing list
> >> Mercurial at selenic.com
> >> http://selenic.com/mailman/listinfo/mercurial
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20100608/1a88dc08/attachment.html>