[Gnu-arch-users] Re: Question about branching a subset

[Andrew Wilcox]

> I got some amazing performance difference between ext3 and reiserFS

Yes, I formatted my own harddisk to resierFS for this reason.

> I don't know how this relates to NTFS, because at the company, we
> primary use windows (2K, 2003).

Couple options: you can try running arch under Windows, or you can run
arch on a Unix server, and export the server's filesystem to your
Windows boxes.

The second scenario allows you to leverage the full power of arch.
For high performance, arch uses features of Unix such as hard links
which are simply not available under Windows.

For the first option, there's a couple of issues.  I don't know if
there's a *mature* port of arch to Windows yet, you'd need to look
into that.  And, you're never going to get the high performance out of
arch on Windows that you do on Unix.

>> * Have a branch off of the software vendor tree to track your
>>   customizations
>
> Is this a branch to merge the changes in the other arch-project?

My suggestion (such as it was), was that you'd have an arch project to
track your software vendor code, and then a branch off of that project
to track your customizations (changes) to the vendor code.

And I'm going to make this vendor code arch project as small as
possible.  My rule of thumb is, I'm going to put everything I can into
my single main arch project, unless I'm pushed to put something (such
as this vendor code) into a different arch project.

Thus, if I had customizations to the vendor's code that consisted of
entirely *new files*, I'd even consider putting those in my main arch
project!

However, *tracking* vendor code needs to go into its own arch project.
And *changes* you make to vendor code files needs to go into a branch
in that arch project, because you're creating patches, and patches to
a file need to be applied against the vendor's particular version of
that file.  That's how I ended up with the suggestion (with what I
know of your situation), of having a separate arch project for the
vendor's code and your changes to the vendor's code.

> ...
>
>> Branches in arch are cheap and easy.  It costs nothing to have lots
>> of them.
>
> Well, here's a little problem. There are a lot of tasks that require
> direct attention. Working ad-hoc requires you to switch often from
> development project. It would cost a lot of diskspace if I need every
> dev-project I'm working on checked out, so I have multiple working
> copies.

How much is "a lot of diskspace"?  10 MB, 100MB, 1GB, 10GB?

I mean, harddisk space these days only costs $100 per 100GB.  It
doesn't take much savings in developer time to pay for A LOT of
harddisk space.

If harddisk space really is a concern, there are a couple options.

You can use "tla get --link" to check out a working tree using hard
links.  Because hard links don't use up any harddisk space (aside from
a tiny bit for the directory entries), you can check out as many
dev-projects as you like.  The only catch is you need to use an editor
that works properly with hard linked files, otherwise you'll corrupt
your revision library.

(Corrupting your revision library is no big deal, arch will tell you
that you've corrupted your revision library and you just rebuild it.
However, to avoid having your developers get mad at each other, I
would recommend that you give each developer their own revision
library, even if you are storing everything on a central server).

If hard links are not an option (you decide to run arch on your
individual Windows boxes, or you using an editor that doesn't work
with hard link files), and you really are concerned about harddisk
space, then...

> Or is it possible to work on development branch A, do some changes,
> switch to dev-branch B, do some changes, commit B, merge with test,
> switch back to dev-branch A. Does A still have the modified files?

Sure, you can "tla undo" to save out your uncommitted changes to a
branch, switch your working directory to a different branch with "tla
apply-delta" (see "Switch to a branch" in
http://wiki.gnuarch.org/Arch_20Recipes for details), do merges,
commits, etc., then switch back to branch A and get your uncommitted
changes back with "tla redo".

However, personally, I'd look at how much it would cost you to have
your developers do this extra work (i.e. your fully loaded cost of
each developer-hour) vs. the cost of buying extra hard disk space (if
you actually need it).

Andrew Wilcox