> 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 _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
