RFC : Shadow Trees

[Adrian Wilkins]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok, I was thinking about things like Bugs Everywhere.

In-tree bug tracking systems have various ups and downs because of their design.
One of the downsides is that they drag a lot of files into your tree, which
might make various operations a lot slower.

I was thinking that specifically to address this downside, it might be nice to
store the data in a format that was compressed into a single file ; Mylyn does
this by zipping up all it's task XMLs. But this then becomes a special problem
for version control ; if you change ANY tracker item, the whole file has a new
revision. And merging can't be done with basic line-based tools, you have to
write some special magic.

Then I realized - I already have a tool that does this, it's called Bazaar, it
squishes all the data into a few large files, it has nice line-based merging.
The only downside is its insistence on duplicating all that data into my working
tree when I don't need it to.

So, my crazy thought of the day ;

What if you could have a tree in your inventory that contained files that by
default, didn't get checked out? In some other respects, a shadow tree would be
normal - you could list it's inventory using bzr ls, cat files within it, etc.
But in a working tree...

 - If something is absent, it's not presumed to be deleted, just unchanged.
 - By default, shadow trees are not checked out onto disk

(and versions that didn't support it could fall back to treating it like a
normal tree)

In this way, if you need to work on a particular item, you can have Bazaar check
it out (and it's ancestors). Deletion is a less desirable case for issue
tracking files (which you typically want to keep), so having to explicitly "bzr
rm" it would be nice.

For Mylyn specifically, bzr (and maybe an indexing plugin) could be used to
query the shadow tree for bug information, and only files that are needed are
checked out and versioned.

I know this sounds a bit mad, but issue trackers can have huge numbers of
entries and adding umpteen files to your tree (esp on that Aperture Oriented
Operating System) can be a real performance sucker.



Crazy Appendix A:

I'd also really like to see a standard for in-tree issue tracking ; a format
that merges easily with text-base tools. I'll have a proper look at BE. At
present I'm using some godawful thing based on XML purely because it was the
only file-based tracker I could find with Eclipse integration, but if I had a
system based on files that was flexible and that Mylyn understood, I'd drop it
like a shot.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJANcAcP1uebIhWSYRAkc/AJ93Sw9ixz8MYuBGaOcH9Kfz90P9+QCggPWF
9nx2NdbfvXkt1Xpq4tuvnes=
=3n3M
-----END PGP SIGNATURE-----