TreeSet.newick gets broken if OTU's are removed from TreeSet.otuSet

[GoogleCodeExporter]

Since TreeSet.otuSet can be shared with other objects, otu's can be added 
to or
removed from TreeSet.otuSet without a TreeSet's knowing about it. Adding 
otu's
might not be bad (see below), but if they are removed then 
TreeSet.newick's
integers won't be right any more.  

Adding otu's might not be bad because any new otu's are added to the end 
of
TreeSet.otus (see MergeToLocalTaxa(Taxa, OTUSet, List<OTU>)) and the 
Newick
integers stay correct. (The Newick integers point at TreeSet.otus - so "1" in
the Newick string is the otu at otus[0]).
[reply] [-] Comment 1 Sam Donnelly 2009-08-11 01:50:57 EDT
The situation has changed for this bug:

Now the stored Newick strings contain the pPOD id's instead of the (fragile)
numbers from Mesquite. 

Now if an OTU is deleted, the pPOD id in the Newick string won't be 
pointing to
anything. Adding OTU's is not a problem at all because there simply won't 
be
references in the tree to them. References can be explicitly added if 
desired.

Original issue reported on code.google.com by snd...@gmail.com on 28 Jan 2010 at 8:34

[GoogleCodeExporter]

Original comment by snd...@gmail.com on 10 Feb 2010 at 8:36

• Added labels: pPOD-CDM
• Removed labels: pPOD-Core

[GoogleCodeExporter]

We now require that an en entire Study including OTUSet, TreeSet's and Tree's 
be loaded into Mesquite. And since a Study exclusively owns an OTUSet which in 
turn explicitly own the TreeSet, this is no longer an issue. Since any deletion 
from the OTUSet will be immediately reflected in the TreeSet and its trees.

Original comment by snd...@gmail.com on 19 Jul 2010 at 2:32

• Changed state: Fixed