[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [stellation-res] Parsing location spec - patch 34576
|
> -----Original Message-----
> From: stellation-res-admin@xxxxxxxxxxxxxxx
> [mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> Chu-Carroll
> Sent: Tuesday, March 11, 2003 9:53 PM
> To: Stellation-res
> Subject: RE: [stellation-res] Parsing location spec - patch 34576
>
>
> On Tue, 2003-03-11 at 20:01, Jonathan Gossage wrote:
> > > -----Original Message-----
> > > From: stellation-res-admin@xxxxxxxxxxxxxxx
> > > [mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> > > Chu-Carroll
> > > Sent: Tuesday, March 11, 2003 7:43 PM
> > > To: Stellation-res
> > > Subject: RE: [stellation-res] Parsing location spec - patch 34576
> > >
> > >
> > > On Tue, 2003-03-11 at 19:17, Jonathan Gossage wrote:
> > > > > -----Original Message-----
> > > > > From: stellation-res-admin@xxxxxxxxxxxxxxx
> > > > > [mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of
> Jim Wright -
> > > > > IBM Research
> > > > > Sent: Tuesday, March 11, 2003 6:27 PM
> > > > > To: stellation-res@xxxxxxxxxxxxxxx
> > > > > Subject: Re: [stellation-res] Parsing location spec - patch 34576
> > > > >
> > > > >
> > > > > Jonathan,
> > > > >
> > > > > I've looked over the patches for #34576, and they
> basically look fine.
> > > > >
> > > > > A couple of points about patch content:
> > > > >
> > > > > 1. You've defined LOCATION_OPTION_SEPARATOR as '+' in the patch.
> > > > > I assume we would want to keep the value as ':' until a different
> > > > > value is
> > > > > agreed?
> > > > >
> > > > > 2. The posted patches include some Firebird-related changes
> > > (e.g. changing
> > > > > from "firebird" to "firebirdsql" in
> > > > > stellation.cli.data.Location.java). These seem reasonable
> > > > > too, but perhaps all the Firebird-enabling changes should go in
> > > > > as a single
> > > > > Bugzilla item?
> > > > >
> > > > > There are also some stray comment headers included in the
> > > patch (no harm
> > > > > done, but
> > > > > a bit extraneous).
> > > > >
> > > > > Some points about patch process:
> > > > >
> > > > > A. The patches were apparently created at varying folder
> > > nesting levels
> > > > > within the five projects being patched (cli, core,
> remote, scm.model,
> > > > > unittest). This made it a bit confusing to review the
> > > patches: I had to
> > > > > figure which folder or individual file was the base node for
> > > each given
> > > > > patch. Mark and I generate patches using the project folder
> > > as the base
> > > > > node; this produces project-relative paths within the
> patch file, and
> > > > > facilitates applying or reviewing the patch.
> > > > >
> > > > > B. The Bugzilla attachment had the name 'attachment.cgi' even
> > > > > though it was
> > > > > a zip file. A similar issue occurred with Bugzilla 34560
> > > (which I just
> > > > > approved,
> > > > > via Bugzila): the attachment for 34560 was a single text file
> > > > > (patch file) that
> > > > > was also named 'attachment.cgi'.
> > > > >
> > > > > Mark has started zipping every patch using the bugzilla number as
> > > > > the patch
> > > > > file name
> > > > > (e.g. 34560.zip would be a zip file containing a single text
> > > file named
> > > > > cli.patch).
> > > > > In a recent patch zip, Mark also included the Bugzilla number
> > > as the path
> > > > > prefix.
> > > > > For #34576, using these conventions, the attachment would be:
> > > > >
> > > > > Archive: 34576.zip
> > > > > 34576/cli.patch
> > > > > 34576/core.patch
> > > > > 34576/remote.patch
> > > > > 34576/scm-model.patch
> > > > > 34576/unittest.patch
> > > > >
> > > > > I like this approach, and will use it for my future patches. It
> > > > > facilitates
> > > > > keeping a single 'patches' directory with all patches neatly
> > > > > organized into
> > > > > folders by Bugzilla number, and also makes it easier to apply
> > > or review
> > > > > patches.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Jim
> > > > >
> > > > >
> > > > > At 06:40 AM 3/11/2003, Jonathan Gossage wrote:
> > > > > >As a follow-up to my earlier post on this subject I have
> > > created a patch
> > > > > >that uses a symbolic definition for the database location
> > > separator. The
> > > > > >patch still uses the problem definition of ':' but this is
> > > easily changed
> > > > > >once we settle on a resolution to the Firebird problem.
> > > > > >
> > > > > >The patch is attached to Bugzilla #34576. Could someone take
> > > a look at it
> > > > > >please?
> > > > > >
> > > > > >Regards
> > > > > >
> > > > > >Jonathan
> > > > I am having a lot of problems with the patch mechanism. I
> > > created .zip files
> > > > with a similar naming convention and I don't know how they got
> > > changed to
> > > > .cgi. Probably a misuse of Bugzilla but I find the patch
> > > submission process
> > > > in Bugzilla a bit obscure.
> > > >
> > > > The reason that the patches were created at different levels
> > > was that I have
> > > > other modifications that I did not want to include so I had to
> > > try and get
> > > > very fine-grained. I thought that I had backed out the use of
> > > '+' and the
> > > > definition of firebirdsql before making the patch. I was
> > > intending to submit
> > > > separate patches for those changes.
> > > >
> > > > In general I am finding the process of creating and sending
> > > patches to be
> > > > very error prone. Hopefully when we can move to Stellation
> > > where we can use
> > > > branches instead of patches this will be easier.
> > >
> > > A couple of points and questions.
> > >
> > > (1) It's an unavoidable problem that making multiple changes
> in the same
> > > workspace inevitably leads to grief. The patch process isn't fun,
> > > but if you limit yourself to one set of changes in at a time in
> > > a workspace, it's not too painful. Unfortunately, Eclipse
> is not great
> > > at dealing with this. The only solution that I've found is to have
> > > several complete Eclipse workspaces, and a set of aliases for
> > > launching Eclipse. When I switch tasks, I exit the running eclipse,
> > > and start the version of Eclipse for the workspace where
> I'm going to
> > > do my next task. Stellation will help with this, because it
> will allow
> > > you to do a checkin to a branch for a change in progress, and then
> > > replace the workspace contents with a different branch to work on a
> > > different task. It will still require you to only work on one change
> > > in any given branch/workspace.
> > >
> > > (2) I think that the Stellation server is ready for self-hosting. All
> > > of the major problems seem to have been fixed. The main thing that
> > > we don't have is working windows client support. Are you close to
> > > having a working client on windows? Is there anything Jim or I can
> > > do to help?
> > >
> > > -Mark
> > >
> > > --
> > I think I am reasonably close, at least for the command line
> stuff, barring
> > major Firebird problems. I have done nothing yet with the
> Eclipse plugin as
> > I wanted to have as solid an infrastructure as possible. Also I
> have not yet
> > tested remote access, either locally or across the network.
> While I have a
> > second Windows machine on a network at home, it is heavily used
> by my son
> > and since it only has 256MB and runs very slowly under Eclipse,
> I have a bit
> > of a scheduling problem.
>
> OK... How about this: I'll set up the current version of Stellation from
> CVS on the self-host server, set up accounts for the committers, and
> have the admins open the firewall. It will not be the real self-hosting
> server, but just a test space so that there's a remote server that
> people can work against. Would that be helpful?
>
> -Mark
>
>
> >
> > Regards
> >
> > Jonathan
That will help in that it will allow testing a Windows client against a
Linux server which should probably be done before we go to proper
self-hosting.
Regards
Jonathan
