gusdev-gusdev

[GUSDEV] bug #33 is marked as fixed but ...

[Fernan A. <fe...@ii...>]

Hi,

I've just noticed that some of the columns that were
proposed to be added in bug #33 are missing from my local
GUS instance (svn checkout of Apr 11th, 2006, which I guess
corresponds to 3.5.1).

The bug was marked as 'fixed' in Dec 2005 ... how do I get
a version of GUS with these changes? 

svn checkout https://www.cbil.upenn.edu/svn/gus/gusTrunk GUS
didn't get those for me

Fernan

Re: [GUSDEV] bug #33 is marked as fixed but ...

[Mark S. H. <mh...@ug...>]

It's fixed in 3.6-Dev

$ svn log -r4310 https://cbil.upenn.edu/svn/gus/GusSchema/branches/ 
3-6-Dev/
------------------------------------------------------------------------
r4310 | msaffitz | 2005-12-11 12:20:06 -0500 (Sun, 11 Dec 2005) | 1 line

fix for 33, Schema changes to capture more information from dbEST and
------------------------------------------------------------------------


On May 8, 2006, at 3:11 PM, Fernan Aguero wrote:

> Hi,
>
> I've just noticed that some of the columns that were
> proposed to be added in bug #33 are missing from my local
> GUS instance (svn checkout of Apr 11th, 2006, which I guess
> corresponds to 3.5.1).
>
> The bug was marked as 'fixed' in Dec 2005 ... how do I get
> a version of GUS with these changes?
>
> svn checkout https://www.cbil.upenn.edu/svn/gus/gusTrunk GUS
> didn't get those for me
>
> Fernan
>
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

Re: [GUSDEV] bug #33 is marked as fixed but ...

[Fernan A. <fe...@ii...>]

+----[ Mark Heiges <mh...@ug...> (08.May.2006 16:35):
|
| It's fixed in 3.6-Dev
| 
| $ svn log -r4310 https://cbil.upenn.edu/svn/gus/GusSchema/branches/ 
| 3-6-Dev/
| ------------------------------------------------------------------------
| r4310 | msaffitz | 2005-12-11 12:20:06 -0500 (Sun, 11 Dec 2005) | 1 line
| 
| fix for 33, Schema changes to capture more information from dbEST and
| ------------------------------------------------------------------------
|
+----]

Thanks Mark,

based on the followup comments for the bug I thought some of
the changes ended up in 3.5.1.

But also, I thought that 'trunk' was the main line of
development, and thus that checking out code from 'trunk'
would get me the latest development snapshot as opposed to
getting code from a branch, which, well, being branched from the
'trunk' is supposed to carry a snapshot + fixes or
development made after branching. But this is all based on
my past experience with CVS.

I'm not too familiar with svn but I was under the impression
that it was a drop-in replacement for CVS with additional
features.

Which leads me to another question (to the SVN meisters):
how's the svn repository laid out, and how is the
development cycle mapped onto the repository? What's the
main line of development? Trunk?

When I browse https://www.cbil.upenn.edu/svn/gus/ I see 
'branches', 'tags' and 'trunk' which to me look pretty much
like CVS. That's why I supposed that 'trunk' was the main
line of development.

Say you've already branched from trunk for 3.6, then any
change made into this branch would have to be merged back
into the trunk in order to be also incorporated into future
releases ... unless there's some svn magic I'm unaware of.

Fernan

Re: [GUSDEV] bug #33 is marked as fixed but ...

[Michael S. <m...@sa...>]

Comments below...

Fernan Aguero wrote:
> +----[ Mark Heiges <mh...@ug...> (08.May.2006 16:35):
> |
> | It's fixed in 3.6-Dev
> | 
> | $ svn log -r4310 https://cbil.upenn.edu/svn/gus/GusSchema/branches/ 
> | 3-6-Dev/
> | ------------------------------------------------------------------------
> | r4310 | msaffitz | 2005-12-11 12:20:06 -0500 (Sun, 11 Dec 2005) | 1 line
> | 
> | fix for 33, Schema changes to capture more information from dbEST and
> | ------------------------------------------------------------------------
> |
> +----]
> 
> Thanks Mark,
> 
> based on the followup comments for the bug I thought some of
> the changes ended up in 3.5.1.
> 
> But also, I thought that 'trunk' was the main line of
> development, and thus that checking out code from 'trunk'
> would get me the latest development snapshot as opposed to
> getting code from a branch, which, well, being branched from the
> 'trunk' is supposed to carry a snapshot + fixes or
> development made after branching. But this is all based on
> my past experience with CVS.
> 
> I'm not too familiar with svn but I was under the impression
> that it was a drop-in replacement for CVS with additional
> features.

Yes...  subversion is intended as a cvs replacement, and the assumption 
that development occurs on the trunk is accurate... except in this case. 
  This is due to historical reasons:  GUS had been a work in progress, 
without discreet releases, and most people were thus used to working 
directly in the trunk.  It was just easier to branch for development and 
keep the trunk stable than change the community's behavior.

> 
> Which leads me to another question (to the SVN meisters):
> how's the svn repository laid out, and how is the
> development cycle mapped onto the repository? What's the
> main line of development? Trunk?

At least when I was working on it (which was up to 1/06), trunk was 
stable and branches/tags contained historical and dev releases.

> 
> When I browse https://www.cbil.upenn.edu/svn/gus/ I see 
> 'branches', 'tags' and 'trunk' which to me look pretty much
> like CVS. That's why I supposed that 'trunk' was the main
> line of development.
> 
> Say you've already branched from trunk for 3.6, then any
> change made into this branch would have to be merged back
> into the trunk in order to be also incorporated into future
> releases ... unless there's some svn magic I'm unaware of.
> 

This is correct.

AFAIK/remember, Schema 3.6 is basically ready to go, but the 
AppFramework components do not yet support it.  3.6 changes were marked 
resolved, but not closed with the assumption that that would occur when 
it was released.

--Mike

> Fernan
> 

Re: [GUSDEV] bug #33 is marked as fixed but ...

[Fernan A. <fe...@ii...>]

+----[ Michael Saffitz <m...@sa...> (08.May.2006 19:31):
| 

[snipped]

| >But also, I thought that 'trunk' was the main line of
| >development, and thus that checking out code from 'trunk'
| >would get me the latest development snapshot as opposed to
| >getting code from a branch, which, well, being branched from the
| >'trunk' is supposed to carry a snapshot + fixes or
| >development made after branching. But this is all based on
| >my past experience with CVS.
| >
| >I'm not too familiar with svn but I was under the impression
| >that it was a drop-in replacement for CVS with additional
| >features.
| 
| Yes...  subversion is intended as a cvs replacement, and the assumption 
| that development occurs on the trunk is accurate... except in this case. 
|  This is due to historical reasons:  GUS had been a work in progress, 
| without discreet releases, and most people were thus used to working 
| directly in the trunk.  It was just easier to branch for development and 
| keep the trunk stable than change the community's behavior.

I see ... but maybe this could be changed in the future? It
gives a more smooth devel roadmap ... at least for me it's
easier to work with branches/tags, as it's always clear what
I'm getting when I choose to download/checkout from a
particular branch/tag.

Or, alternatively, do not branch the code. If people feel
more comfortable without discreet releases, then keep
development in the trunk and only 'tag' the tree at
particular times (a release), a major event (ie. a
publication), like it's been already done for GUS. In this
case branching creates a confusion (latest code in the
branch but not in the trunk), and a load on the maintainer
of the repository as s/he will have to merge back all the
changes to trunk when work in a new release starts ...

| >Which leads me to another question (to the SVN meisters):
| >how's the svn repository laid out, and how is the
| >development cycle mapped onto the repository? What's the
| >main line of development? Trunk?
| 
| At least when I was working on it (which was up to 1/06), trunk was 
| stable and branches/tags contained historical and dev releases.

OK.

| >When I browse https://www.cbil.upenn.edu/svn/gus/ I see 
| >'branches', 'tags' and 'trunk' which to me look pretty much
| >like CVS. That's why I supposed that 'trunk' was the main
| >line of development.
| >
| >Say you've already branched from trunk for 3.6, then any
| >change made into this branch would have to be merged back
| >into the trunk in order to be also incorporated into future
| >releases ... unless there's some svn magic I'm unaware of.
| 
| This is correct.

A nice load over the shoulders of the repository meister :)

| AFAIK/remember, Schema 3.6 is basically ready to go, but the 
| AppFramework components do not yet support it.  3.6 changes were marked 
| resolved, but not closed with the assumption that that would occur when 
| it was released.

Got it.

Thanks for the clarification. And good luck with your new
job! (I just knew about it)

Fernan

| 
| --Mike
|
+----]