Board index » off-topic » Folder Organization

Folder Organization


2006-11-01 10:39:39 PM
off-topic12
We want to keep some of our component source in StarTeam, more to share our
components that really VC'ing them (they hardly ever change).
I've already added one component into StarTeam, which of course shows as
it's own project. I realized after the fact I'd really like all our
components to show up under a root folder called something like '2006
Components', then have all the components under that folder.
Is this possible or does each of the components need to be loaded/displayed
as a seperate project? If so how can I move the existing folders to the
(new) folder?
TIA -
Jeff
 
 

Re:Folder Organization

Don't know if this is what you're asking, but you can setup several
views under the same project and have each view work essentially like
its own project. When creating the view, do NOT check "Derive new view
from current view". If you do that, the new view will have a completely
independent set of files, labels and other items, so, it's like a
totally separate project.
I've been using that approach to put several small porjects under a
common StarTeam project and be able to organize them in a hierarchy.
Kjell
J. Clarke wrote:
Quote
We want to keep some of our component source in StarTeam, more to share our
components that really VC'ing them (they hardly ever change).

I've already added one component into StarTeam, which of course shows as
it's own project. I realized after the fact I'd really like all our
components to show up under a root folder called something like '2006
Components', then have all the components under that folder.

Is this possible or does each of the components need to be loaded/displayed
as a seperate project? If so how can I move the existing folders to the
(new) folder?
--
---------------------------------------------------------------------------
Kjell Rilbe
Home: +46 8 7610734
Cell: +46 733 442464
---------------------------------------------------------------------------
"If there's a price for bein' me, that's one I'll have to pay"
Aaron Tippin
---------------------------------------------------------------------------
 

Re:Folder Organization

Hmm that sounds like what I want. Except the Wizard walked me thru the 1st
project so now my top level folder is the project name with the actual files
in subdirectories under it.
Essentially I want to have a hierarchy more like:
Components for D2006
- ComponentA (It's own project)
- ComponentB (It's own project)
- ComponentC (It's own project)
- ...
It's more for organization than anything to help quickly locate stuff.
Then I have another example of a similar kind. My product line has 1
product. This individual product is made up (currently) of 236 individual
Delphi Projects. In the Root level I don't want to see 236 individual
projects, just the actual 'product' with all the individual projects below
it. Is that confusing?
Jeff
"Kjell Rilbe" < XXXX@XXXXX.COM >wrote in message
Quote
Don't know if this is what you're asking, but you can setup several views
under the same project and have each view work essentially like its own
project. When creating the view, do NOT check "Derive new view from
current view". If you do that, the new view will have a completely
independent set of files, labels and other items, so, it's like a totally
separate project.

I've been using that approach to put several small porjects under a common
StarTeam project and be able to organize them in a hierarchy.

Kjell

J. Clarke wrote:

>We want to keep some of our component source in StarTeam, more to share
>our components that really VC'ing them (they hardly ever change).
>
>I've already added one component into StarTeam, which of course shows as
>it's own project. I realized after the fact I'd really like all our
>components to show up under a root folder called something like '2006
>Components', then have all the components under that folder.
>
>Is this possible or does each of the components need to be
>loaded/displayed as a seperate project? If so how can I move the
>existing folders to the (new) folder?
--
---------------------------------------------------------------------------
Kjell Rilbe
Home: +46 8 7610734
Cell: +46 733 442464
---------------------------------------------------------------------------
"If there's a price for bein' me, that's one I'll have to pay"
Aaron Tippin
---------------------------------------------------------------------------
 

{smallsort}

Re:Folder Organization

We have to distinguish between "StarTeam project", "Delphi project",
"StarTeam view", "StarTeam folder" and "Windows folder". These are five
distinctly different things, and unless you understand the differences
you will find it difficult to understand how to get what you want out of
StarTeam.
Please read up on those concepts first. I'll write a short summary here:
1. "StarTeam project": This is a top-level container in StarTeam. You
cannot have a hierarchy of ST projects - you will always see them listed
in a straight alphabetical list. Each ST project contains one or more ST
views.
2. "Delphi project": This is in StarTeam's world just a set of folders
and files. I assume you knwo what it is in non-StarTeam terms.
3. "StarTeam view": This is a second-to-top level container in StarTeam.
Each veiw contains a set of StarTeam folders and files (and CR:s etc.).
Views can be organized into a hierarchy. A view can be derived from its
parent view or independent from it.
4. "StarTeam folder": This is a container, very much like a Windows
folder, but the StarTeam folder tree might not be identical with a
folder tree in Windows, since each ST folder can specify any working
(Windows) folder, including a relative or absolute Windows path.
5. "Windows folder": I assume you know what this is.
What I suggested (tridd to suggest) was to create one single ST project
for your product.
Then create one ST view for each Delphi project that's part of your
product. If you want to be able to create separate view labels etc for
each Delphi project, each view should NOT derive from the top/parent view.
If you want to be able to label the entire product with a single view
label in the top view, then you need to put all of your Delphi projects
in there. In that case other's might have good suggestiong on how to
ALSO be able to handle each Delphi project separately, with its own set
of view labels, separate from the product/top view labels.
Kjell
J. Clarke wrote:
Quote
Hmm that sounds like what I want. Except the Wizard walked me thru the 1st
project so now my top level folder is the project name with the actual files
in subdirectories under it.

Essentially I want to have a hierarchy more like:

Components for D2006
- ComponentA (It's own project)
- ComponentB (It's own project)
- ComponentC (It's own project)
- ...

It's more for organization than anything to help quickly locate stuff.

Then I have another example of a similar kind. My product line has 1
product. This individual product is made up (currently) of 236 individual
Delphi Projects. In the Root level I don't want to see 236 individual
projects, just the actual 'product' with all the individual projects below
it. Is that confusing?

Jeff

"Kjell Rilbe" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...

>Don't know if this is what you're asking, but you can setup several views
>under the same project and have each view work essentially like its own
>project. When creating the view, do NOT check "Derive new view from
>current view". If you do that, the new view will have a completely
>independent set of files, labels and other items, so, it's like a totally
>separate project.
>
>I've been using that approach to put several small porjects under a common
>StarTeam project and be able to organize them in a hierarchy.
>
>Kjell
>
>J. Clarke wrote:
>
>
>>We want to keep some of our component source in StarTeam, more to share
>>our components that really VC'ing them (they hardly ever change).
>>
>>I've already added one component into StarTeam, which of course shows as
>>it's own project. I realized after the fact I'd really like all our
>>components to show up under a root folder called something like '2006
>>Components', then have all the components under that folder.
>>
>>Is this possible or does each of the components need to be
>>loaded/displayed as a seperate project? If so how can I move the
>>existing folders to the (new) folder?
--
---------------------------------------------------------------------------
Kjell Rilbe
Home: +46 8 7610734
Cell: +46 733 442464
---------------------------------------------------------------------------
"If there's a price for bein' me, that's one I'll have to pay"
Aaron Tippin
---------------------------------------------------------------------------
 

Re:Folder Organization

Thanks Kjell. Definately still learning. We are moving from the Jedi VCS
to StarTeam so some of the concepts are different then we used there. I've
been weeding thru the ST web based training. Can't wait till it 'clicks' -
LOL. It's obvious I need to understand views more thats for sure.
Jeff
"Kjell Rilbe" < XXXX@XXXXX.COM >wrote in message
Quote
We have to distinguish between "StarTeam project", "Delphi project",
"StarTeam view", "StarTeam folder" and "Windows folder". These are five
distinctly different things, and unless you understand the differences you
will find it difficult to understand how to get what you want out of
StarTeam.

Please read up on those concepts first. I'll write a short summary here:

1. "StarTeam project": This is a top-level container in StarTeam. You
cannot have a hierarchy of ST projects - you will always see them listed
in a straight alphabetical list. Each ST project contains one or more ST
views.

2. "Delphi project": This is in StarTeam's world just a set of folders and
files. I assume you knwo what it is in non-StarTeam terms.

3. "StarTeam view": This is a second-to-top level container in StarTeam.
Each veiw contains a set of StarTeam folders and files (and CR:s etc.).
Views can be organized into a hierarchy. A view can be derived from its
parent view or independent from it.

4. "StarTeam folder": This is a container, very much like a Windows
folder, but the StarTeam folder tree might not be identical with a folder
tree in Windows, since each ST folder can specify any working (Windows)
folder, including a relative or absolute Windows path.

5. "Windows folder": I assume you know what this is.

What I suggested (tridd to suggest) was to create one single ST project
for your product.

Then create one ST view for each Delphi project that's part of your
product. If you want to be able to create separate view labels etc for
each Delphi project, each view should NOT derive from the top/parent view.

If you want to be able to label the entire product with a single view
label in the top view, then you need to put all of your Delphi projects in
there. In that case other's might have good suggestiong on how to ALSO be
able to handle each Delphi project separately, with its own set of view
labels, separate from the product/top view labels.

Kjell

J. Clarke wrote:
>Hmm that sounds like what I want. Except the Wizard walked me thru the
>1st project so now my top level folder is the project name with the
>actual files in subdirectories under it.
>
>Essentially I want to have a hierarchy more like:
>
>Components for D2006
>- ComponentA (It's own project)
>- ComponentB (It's own project)
>- ComponentC (It's own project)
>- ...
>
>It's more for organization than anything to help quickly locate stuff.
>
>Then I have another example of a similar kind. My product line has 1
>product. This individual product is made up (currently) of 236
>individual Delphi Projects. In the Root level I don't want to see 236
>individual projects, just the actual 'product' with all the individual
>projects below it. Is that confusing?
>
>Jeff
>
>"Kjell Rilbe" < XXXX@XXXXX.COM >wrote in message
>news: XXXX@XXXXX.COM ...
>
>>Don't know if this is what you're asking, but you can setup several views
>>under the same project and have each view work essentially like its own
>>project. When creating the view, do NOT check "Derive new view from
>>current view". If you do that, the new view will have a completely
>>independent set of files, labels and other items, so, it's like a totally
>>separate project.
>>
>>I've been using that approach to put several small porjects under a
>>common StarTeam project and be able to organize them in a hierarchy.
>>
>>Kjell
>>
>>J. Clarke wrote:
>>
>>
>>>We want to keep some of our component source in StarTeam, more to share
>>>our components that really VC'ing them (they hardly ever change).
>>>
>>>I've already added one component into StarTeam, which of course shows as
>>>it's own project. I realized after the fact I'd really like all our
>>>components to show up under a root folder called something like '2006
>>>Components', then have all the components under that folder.
>>>
>>>Is this possible or does each of the components need to be
>>>loaded/displayed as a seperate project? If so how can I move the
>>>existing folders to the (new) folder?


--
---------------------------------------------------------------------------
Kjell Rilbe
Home: +46 8 7610734
Cell: +46 733 442464
---------------------------------------------------------------------------
"If there's a price for bein' me, that's one I'll have to pay"
Aaron Tippin
---------------------------------------------------------------------------
 

Re:Folder Organization

Yes, view are a very central concept in StarTeam and you can both do a
lot of useful stuff and "shoot yourself in your foot" with them. If you
decide to use sharing at all, make sure you know what you're doing.
There are several pitfalls there.
Kjell
J. Clarke wrote:
Quote
Thanks Kjell. Definately still learning. We are moving from the Jedi VCS
to StarTeam so some of the concepts are different then we used there. I've
been weeding thru the ST web based training. Can't wait till it 'clicks' -
LOL. It's obvious I need to understand views more thats for sure.
--
---------------------------------------------------------------------------
Kjell Rilbe
Home: +46 8 7610734
Cell: +46 733 442464
---------------------------------------------------------------------------
"If there's a price for bein' me, that's one I'll have to pay"
Aaron Tippin
---------------------------------------------------------------------------
 

Re:Folder Organization

You wouldn't happen to have any suggested reading? The user manual (PDF) is
kinda light on views.
Just curious - Do you guys place any of your 3rd party VCL controls in ST?
Jeff
"Kjell Rilbe" < XXXX@XXXXX.COM >wrote in message
Quote
Yes, view are a very central concept in StarTeam and you can both do a lot
of useful stuff and "shoot yourself in your foot" with them. If you decide
to use sharing at all, make sure you know what you're doing. There are
several pitfalls there.

Kjell

J. Clarke wrote:

>Thanks Kjell. Definately still learning. We are moving from the Jedi
>VCS to StarTeam so some of the concepts are different then we used there.
>I've been weeding thru the ST web based training. Can't wait till it
>'clicks' - LOL. It's obvious I need to understand views more thats for
>sure.
--
---------------------------------------------------------------------------
Kjell Rilbe
Home: +46 8 7610734
Cell: +46 733 442464
---------------------------------------------------------------------------
"If there's a price for bein' me, that's one I'll have to pay"
Aaron Tippin
---------------------------------------------------------------------------
 

Re:Folder Organization

J. Clarke wrote:
Quote
You wouldn't happen to have any suggested reading? The user manual
(PDF) is kinda light on views.
There is a "best practices" document which you should be able to find
via Google which gives about six different options for using views.
Here's what we do, which is AFAICS fairly standard practice:
o Everyone works in default view.
o Immediately after a release is finalized, we create a derived view
for that release. The view is set to freeze to the current time, and
branch on change.
o Development of the next release continues in the main view.
o When we need to do a service pack, we implement the features in the
main view and then either float the derived view's corresponding items
to tip (and then freeze again) or branch the corresponding items if
there have been too extensive changes in the main view to float them.
CRs we share into the derived view and have them branch on change,
since they're fixed in two places (the derived view and the main view).
As for third-party controls, yes we have them in there but I've never
been happy with how we do it so I won't give advice. :)
-Craig
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
Everything You Need to Know About InterBase Character Sets:
blogs.teamb.com/craigstuntz/articles/403.aspx
 

Re:Folder Organization

Sorry, no suggestions for reading about views. Read the user manual and
online help and experiment, then do it again, until you understand
everything it says. :-)
Seriously, setup a small test project on a test server configuration
that you can play with at will. Before you want to do something, try it
out on the test server and make sure it has the effect you desire. Ask
here if what you're planning to do is a good idea, and if there are any
pitfalls.
I've placed 3rd party stuff under version control, yes. You will
probably need to do that to be able to keep track of which version of
your stuff works with which version of each 3:rd party package.
Kjell
J. Clarke wrote:
Quote
You wouldn't happen to have any suggested reading? The user manual (PDF) is
kinda light on views.

Just curious - Do you guys place any of your 3rd party VCL controls in ST?

Jeff
--
---------------------------------------------------------------------------
Kjell Rilbe
Home: +46 8 7610734
Cell: +46 733 442464
---------------------------------------------------------------------------
"If there's a price for bein' me, that's one I'll have to pay"
Aaron Tippin
---------------------------------------------------------------------------
 

Re:Folder Organization

Thanks Craig - Searching for that document. I guess part a big part is the
heiracrchal structure I want the users to see more than anything.
"Craig Stuntz [TeamB]" < XXXX@XXXXX.COM [a.k.a. acm.org]>wrote
in message news:4550b90e$ XXXX@XXXXX.COM ...
Quote
J. Clarke wrote:

>You wouldn't happen to have any suggested reading? The user manual
>(PDF) is kinda light on views.

There is a "best practices" document which you should be able to find
via Google which gives about six different options for using views.
Here's what we do, which is AFAICS fairly standard practice:
 

Re:Folder Organization

...so it's worth it to setup an additional server for test projects then?
"Kjell Rilbe" < XXXX@XXXXX.COM >wrote in message
Quote
Sorry, no suggestions for reading about views. Read the user manual and
online help and experiment, then do it again, until you understand
everything it says. :-)

Seriously, setup a small test project on a test server configuration that
you can play with at will. Before you want to do something, try it out on
the test server and make sure it has the effect you desire. Ask here if
what you're planning to do is a good idea, and if there are any pitfalls.

I've placed 3rd party stuff under version control, yes. You will probably
need to do that to be able to keep track of which version of your stuff
works with which version of each 3:rd party package.

 

Re:Folder Organization

YY YY EEEEEE SSSSS !!
YY YY EE SS !!
YYYY EEEE SSSS !!
YY EE SS
YY EEEEEE SSSSS !!
:-)
But you don't need a separate machine, just setup a separate StarTeam
server configuration on the same server as your normal StarTeam server
configuration, or on your workstation.
Some people here even do a regular copy from the production server
config to the test config just to be able to test things on a server
config that contains real-world data.
Kjell
J. Clarke wrote:
Quote
...so it's worth it to setup an additional server for test projects then?

"Kjell Rilbe" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...

>Sorry, no suggestions for reading about views. Read the user manual and
>online help and experiment, then do it again, until you understand
>everything it says. :-)
>
>Seriously, setup a small test project on a test server configuration that
>you can play with at will. Before you want to do something, try it out on
>the test server and make sure it has the effect you desire. Ask here if
>what you're planning to do is a good idea, and if there are any pitfalls.
>
>I've placed 3rd party stuff under version control, yes. You will probably
>need to do that to be able to keep track of which version of your stuff
>works with which version of each 3:rd party package.
>


--
---------------------------------------------------------------------------
Kjell Rilbe
Home: +46 8 7610734
Cell: +46 733 442464
---------------------------------------------------------------------------
"If there's a price for bein' me, that's one I'll have to pay"
Aaron Tippin
---------------------------------------------------------------------------
 

Re:Folder Organization

J. Clarke wrote:
Quote
...so it's worth it to setup an additional server for test projects
then?
Yes. It's hard to emphasize this strongly enough. As Kjell says, just
use a separate server configuration rather than a separate physical
server.
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
Please read and follow Borland's rules for the user of their
server: support.borland.com/entry.jspa
 

Re:Folder Organization

LOL...actually I had talked to my IT manager today about that (even tho I
have enuf priv to setup a new one) we hadn't backed up our initial setup
yet.
One thing I noticed is that the MSDE seemed to want all the room on the disk
from our initial setup for itself. Do I actually need to go into SQL to
pare it back so I have enuf room for the test server instance?
"Kjell Rilbe" < XXXX@XXXXX.COM >wrote in message
Quote
YY YY EEEEEE SSSSS !!
YY YY EE SS !!
YYYY EEEE SSSS !!
YY EE SS YY EEEEEE SSSSS !!

:-)

But you don't need a separate machine, just setup a separate StarTeam
server configuration on the same server as your normal StarTeam server
configuration, or on your workstation.

Some people here even do a regular copy from the production server config
to the test config just to be able to test things on a server config that
contains real-world data.
 

Re:Folder Organization

Dunno about MSDE config and requirements. I do know that I have five
StarTeam server configurations on my machine and I only have one MSDE
instance serving all five.
Kjell
J. Clarke wrote:
Quote
LOL...actually I had talked to my IT manager today about that (even tho I
have enuf priv to setup a new one) we hadn't backed up our initial setup
yet.

One thing I noticed is that the MSDE seemed to want all the room on the disk
from our initial setup for itself. Do I actually need to go into SQL to
pare it back so I have enuf room for the test server instance?
--
---------------------------------------------------------------------------
Kjell Rilbe
Home: +46 8 7610734
Cell: +46 733 442464
---------------------------------------------------------------------------
"If there's a price for bein' me, that's one I'll have to pay"
Aaron Tippin
---------------------------------------------------------------------------