Tree Transform passing all tests, plus abuse

[John A Meinel]

Aaron Bentley wrote:
> John A Meinel wrote:
> |>Okay: how about
> |>
> |>get_id_tree      -> trans_id_tree_file_id
> |>get_trans_id     -> trans_id_file_id
> |>get_tree_path_id -> trans_id_tree_path
> |>get_tree_file_id -> tree_file_id
> |>final_file_id    -> final_file_id (unchanged)
> |>inactive_file_id -> inactive_file_id (unchanged)
> |>
> |>I haven't done this yet, but what do you think?
> |
> |
> | I feel like we need some sort of 'from' in there. like
> | 'trans_id_from_tree_file_id'.
> 
> That's quite a lengthy function name, which was why I wasn't putting
> 'from' in there.
> 

It is long, and I don't really like it. It was just more clear.

> Though it still isn't obvious what the
> | difference is between 'trans_id_tree_file_id' and 'trans_id_file_id'.
> 
> trans_id_tree_file_id returns the trans_id of the file that has the
> specified file_id in the tree.  After the transform is applied, a
> different trans_id may be associated with the file_id.
> 
> trans_id_file_id returns the trans_id currently associated with the
> file_id, if there is one.  If not, it invents a trans_id, and associates
> it with the file_id.
> 
> | I also don't need the commands to be fully self documenting either.
> |
> | What is the specific difference between the two above, and why can't we
> | just have a 'get_trans_id' which takes a file id, and returns a
> | transaction id.
> 
> Sometimes we want to refer to the tree file ids, specifically, sometimes
> we just care about the final file ids.  I think there's no getting
> around it.
> 
> | Or maybe something like
> |
> | get_tree_file_id => file_id_of()
> 
> That would be wrong, because tree_file_id is not the same as final_file_id.
> 
> Aaron

I guess my question is why do we need the tree_file_id based on path.
Don't we usually just need the path based on file id? I realize there is
probably 1 case (you need to check the target tree id for where you are
planning on putting the file).

Overall, I don't think we've had any major insight that lets us do any
better than what we already have. So +1 to the branch. As we are doing
with Robert's work, we'll let the rest sort itself out after it is
inside the codebase.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060220/2b2c15f4/attachment.pgp