nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Empy Initial Workarea

System

I need to make a new workarea in an existing Branch based upon the Initial empty edition. Problem is, I now longer have the original empty Initial Edition.

How can I create an empty workarea without the Initial Edition?

Find more posts tagged with

Comments

Migrateduser

You could create a new workarea and then delete all of the top-level files and directories. But this would be dangerous. If you ever submit from this workarea you run the risk of removing content that is already in STAGING.

Brinko Kobrin
Interwoven Staff Engineer

Migrateduser

That won't work for me. I have tons of submitted data and deleting the xmldata contents in a workarea deletes them from the Staging folder.

Migrateduser

Deleting files in a workarea should not itself delete them from staging. You would need to submit the deletions.

Brinko Kobrin
Interwoven Staff Engineer

nipper

As brinko said this is very dangerous. I would not do it.

How about making another branch ? You can copy to area the content you need (if you need any)
and create the new WA from the initial edition.

I am curious what you are trying to do

Andy

Migrateduser

In this new workarea I don't want the users to see the xml files in the xml data (the submitted files) from the Editions I have to base it upon. I want a clean slate with nothing in the WorkArea at all. Zilch, zero, nada.

Migrateduser

The users want it under the same branch. (Ie. Branch1)

Here is my structure

//teamsite/default/main/Branch1/WORKAREA/Sales
//teamsite/default/main/Branch1/WORKAREA/Service

I want to create the following, but with nothing in it.

//teamsite/default/main/Branch1/WORKAREA/NewWorkArea

I don't have the INITIAL Edition to work with in this Branch. My editions start at #13.

ts_user

As Brinko said, create a new workarea and delete all the files and directories in the workarea. This will give you a clean workarea with no files or directories. Make sure you publish an edition so that you always have an Edition you go back to. Restrict the access to the workarea or inform the users working in it not to submit with overwrite to the staging area or else ** All content in the STAGING area will be wiped out **. If someone does that accidently, you can use the edition you published to re-populate the STAGING area.
All said **** It is very dangerous to have a empty workarea where users have ability to submit files directly ( using submit-direct and not through workflow) ****

Migrateduser

I don't fully understand what you are trying to achieve by creating this empty workarea. However, here is a procedure that you could consider using.

1. Get all of your users to stop using the branch.
2. Create a new edition. (Let's call it SNAP.)
3. Create a new workarea. Delete all of the content in this workarea. Submit all of the changes from the workarea. Now STAGING should be empty (except for holes).
4. Create a new edition. (Let's call it EMPTY.)
5. Now rollback the branch to edition SNAP.
6. Give your users the "all clear" to resume working in the branch.

You can now create new workareas based upon edition EMPTY.

Brinko Kobrin
Interwoven Staff Engineer

Migrateduser

Brinko, your last solution sounds like the best solution. I think it may work. I'll give it a try and let you know how it worked.

nipper

How do you avoid collisions ? I assume you never do a get latest/update task.

Are there directories under one and not the other ?

i.e.

branch/WA/service/svc_dir_1

branch/WA/sales/sales_dir_1

etc ?

If you do, what is the advantage of this over different branches for each ?

just curious (what you were smoking when you set this up)

Andy

Migrateduser

I am happy and unhappy to say "I inherited this from someone else who set up the whole darn mess".

So, this is what I have to work with. Each workarea contains different folders and corresponds to a different part of the website (yuck). It should be setup so that each workarea is used by a different user. Currently a set of users goes into one workarea called Sales (this contains dcr's for one portion of the site) and another group goes into Service (this contains dcr's for a different section of the site)

See attachment

nipper

K

that was what I thought.

We had a group do that here before, I beat on them to give up
that idea & made seperate branches. On paper that can work, but if
someone does a get latest or somethign then you are hosed.

I was also concerned when some people wanted to remove directories
and not submit them

Again, this is a big gun, don't shoot yourself. Though it does sound as if
you've been running like this for a while, so your users may be OK with it.

Andy

Adam Stoller

I had a similar experience as Nipper - and spent the better part of a day: (1) teaching them about how TeamSite works, (2) explaining how to use OS-level permissions on the directories to control who had access to naviagate through and create files within them, and (3) explaining how to use the submit.cfg.

You may have inherited the mess - but you would do better to fix it than to propagate it further.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

Let me run my proposed structure past you and see what you think. I am assuming this is the typical out of the box way to setup more than on site

//nt16/default/main/Website1
//nt16/default/main/Website1/Sales
//nt16/default/main/Website1/Sales/WORKAREA/Beth
//nt16/default/main/Website1/Sales/WORKAREA/Jen
//nt16/default/main/Website1/Service
//nt16/default/main/Website1/Service/WORKAREA/Beth
//nt16/default/main/Website1/Service/WORKAREA/Jen

//nt16/default/main/Website2
//nt16/default/main/Website2/Support
//nt16/default/main/Website2/Support/WORKAREA/Beth
//nt16/default/main/Website2/Support/WORKAREA/Jen
See attachment for a better visual.

Migrateduser

Or possible this setup. It's a little easier to maintain since I just lump all the users who are going to edit Sales into a Sales Group. This is somewhat similar to what we have now in the fact that each user doesn't have their own workarea. (like I mentioned before, a little easier to maintain) Between the two I presented are their any drawbacks to either that you can see?

nipper

These become personal preference. My gut feeling tells me that you should use branches with common workarea
(Sales, Service, etc branches) each with one WA. Let your users work with that.

The other option, with personal workareas, will require many updatetasks in the WF or for people to get latest.
Both of those options are error prone, but for techical users it works nicely.

For frame of reference, I have almost 200 users (total) in 1 WA, maybe 20-30 at once. Very little
contention on these assets.

HTH

Andy

Migrateduser

Problems resulting from failure to GetLatest can be drastically reduced by event-driven updates. For example in my own primary workarea a build causes an update, so all the files I haven't changed are updated from the most recent "passed" edition. That is the edition that has been through all the predeployment tests. To get content from STAGING that hasn't passed testing yet, I have to do that on purpose. But I get QA'd content automatically. It's a big help.