[
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 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.
Regards
Jonathan
