Mon 01 Dec 2003 11:04:00 PM UTC, comment #12:
Merged into lord@emf.net--2003b/tla--devo--1.1 - thanks pau for doing the initial work.
|
Wed 19 Nov 2003 09:49:39 PM UTC, comment #11:
merged into rbtcollins@hotmail.com--barch/tla--integration--1.1--patch-24
|
Wed 19 Nov 2003 08:33:09 PM UTC, comment #10:
Ok, I've coded up a consistency check for library_find, opening another bug with it's details.
|
Sat 15 Nov 2003 03:28:30 AM UTC, comment #9:
Code that goes into the main distribution needs to be robust. As I said - I'll happily merge this -once- the validation code to prevent accidental SNAFU's is in place. While giving the user rope is a good thing, getting this wrong would be quite a headache for the user - a corrupted archive could result (at worst), and at best their changes wouldn't get committed - they'd lose data in that they couldn't backout changes or recover previous version. I appreciate the importance to folk in large projects, and the preload trick to break hardlinks automatically may be useful too.
So strictly speaking: the validation code is needed before I merge this. If Tom decides to pick it up as is - so be it.
|
Thu 13 Nov 2003 07:01:48 AM UTC, comment #8:
I cannot devote time right now to adding the validation code to the revision libraries, I'm waaaay to busy. Strictly speaking, this extra check is not necessary for you to take the patch as it is another feature that should be added to the revision libraries routines (check somehow that stored files are the same than expected).
But the code includes a big enough warning telling you to be careful. The really missing part is to add the proper documentation, explain there how to setup emacs and vi and warn about the perils of not breaking hardlinks. I would gladly do this really soon if the patch goes mainline.
I really think that the validation code should not be a showstopper to include the hardlinks hack; it's very importnt for people involved in large projects blah blah blah (everything explained in previous c0mments).
|
Thu 13 Nov 2003 01:22:31 AM UTC, comment #7:
Any progress on the TODO:
-Add validation code, using inode-sigs, to the library operations to eliminate the risks of corrupting the archive in case that you modify it.
This validation will be worth to all the routines that use libraries as it will check its
?
|
Sat 08 Nov 2003 11:57:19 AM UTC, comment #6:
I'll be happy to merge this into the integration branch I've created - once you've completed the TODO's that will prevent damaging side effects.
|
Thu 02 Oct 2003 08:06:38 AM UTC, comment #5:
Availabe as tla--devo--1.1--patch-3 (both get and build-config at the same time)
|
Thu 02 Oct 2003 08:04:18 AM UTC, comment #4:
Option --hard-links renamed to --link and -l as the shortcut.
This way we keep the same name than cp for the same option.
Thanks Miles!
|
Thu 02 Oct 2003 08:02:12 AM UTC, comment #3:
Already done!
I have implemented an option to the get command called "hard-links".
I've tested it and works flawlessly :) YMMV
It should be useful to CAREFUL people who:
-have many branches derived from the same trunk
-need speedy gets
-know the implications of working on hard linked files
-copy-on-write when saving files
Cons
-----
-The immediate danger is that you CAN CORRUPT the archive if you modify the the files without breaking the hardlinks.
-It needs to build revision lbraries to link to (obviously you need to define my-default-library).
-Library and tree have to be in the same device (no hardlinks across devices).
Pros
-Lightening fast gets
-Space preservation
TODO
-Add validation code, using inode-sigs, to the library operations to eliminate the risks of corrupting the archive in case that you modify it.
This validation will be worth to all the routines that use libraries as it will check its validity.
Availability
------------
-I've built a public arch to host these changes:
You can cherry-pick the patch to implement it directly from:
linuxnow@newtral.org--arch-2003/tla--devo--1.1--patch-1
|
Thu 02 Oct 2003 06:20:46 AM UTC, comment #2:
Note that the gnu cp option for this is `--link' (short: `-l'); it might be a good idea to use the same option name for tla.
|
Thu 02 Oct 2003 06:09:04 AM UTC, comment #1:
Already done!
I have implemented an option to the get command called "hard-links".
I've tested it and works flawlessly :) YMMV
It should be useful to CAREFUL people who:
-have many branches derived from the same trunk
-need speedy gets
-know the implications of working on hard linked files
-copy-on-write when saving files
Cons
-----
-The immediate danger is that you CAN CORRUPT the archive if you modify the the files without breaking the hardlinks.
-It needs to build revision lbraries to link to (obviously you need to define my-default-library).
-Library and tree have to be in the same device (no hardlinks across devices).
Pros
-Lightening fast gets
-Space preservation
TODO
-Add validation code, using inode-sigs, to the library operations to eliminate the risks of corrupting the archive in case that you modify it.
This validation will be worth to all the routines that use libraries as it will check its validity.
Availability
------------
-I've built a public arch to host these changes:
You can cherry-pick the patch to implement it directly from:
linuxnow@newtral.org--arch-2003/tla--devo--1.1--patch-1
|
Tue 30 Sep 2003 08:32:52 PM UTC, original submission:
An option to get a revision very fast would be to hardlink it against a revision library, building the library if necessary.
It would be up to the user to break the hardlinks on edited files, so it should warn loudly about the risks.
I think that the code would be almost the same than library-add.
|