[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-gnu-arch] [bug #5644] tla get --hardlinks
From: |
nobody |
Subject: |
[Bug-gnu-arch] [bug #5644] tla get --hardlinks |
Date: |
Fri, 14 Nov 2003 22:28:32 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20031010 Mozilla Firebird/0.6.1 StumbleUpon/1.76 |
=================== BUG #5644: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5644&group_id=4899
Changes by: Robert Collins <address@hidden>
Date: Sat 11/15/2003 at 03:28 (GMT)
------------------ Additional Follow-up Comments ----------------------------
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.
=================== BUG #5644: FULL BUG SNAPSHOT ===================
Submitted by: paulinux Project: GNU arch -- a revision control
system
Submitted on: Tue 09/30/2003 at 20:32
Category: tla Severity: 5 - Major
Bug Group: small feature idea Resolution: None
Status: Open Release: tla--devo-1.1
Fixed Release: Merge Request?: None
Your Archive Name: Your Archive Location:
Assigned to: None
Summary: tla get --hardlinks
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.
Follow-up Comments
*******************
-------------------------------------------------------
Date: Sat 11/15/2003 at 03:28 By: robertc
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.
-------------------------------------------------------
Date: Thu 11/13/2003 at 07:01 By: paulinux
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).
-------------------------------------------------------
Date: Thu 11/13/2003 at 01:22 By: robertc
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
?
-------------------------------------------------------
Date: Sat 11/08/2003 at 11:57 By: robertc
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.
-------------------------------------------------------
Date: Thu 10/02/2003 at 08:06 By: paulinux
Availabe as tla--devo--1.1--patch-3 (both get and build-config at the same time)
-------------------------------------------------------
Date: Thu 10/02/2003 at 08:04 By: paulinux
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!
-------------------------------------------------------
Date: Thu 10/02/2003 at 08:02 By: paulinux
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:
* archive name: address@hidden
* location: http://arch.newtral.org/{archives}/arch-2003
* project: address@hidden/tla--devo--1.1
You can cherry-pick the patch to implement it directly from:
address@hidden/tla--devo--1.1--patch-1
-------------------------------------------------------
Date: Thu 10/02/2003 at 06:20 By: miles
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.
-------------------------------------------------------
Date: Thu 10/02/2003 at 06:09 By: paulinux
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:
* archive name: address@hidden
* location: http://arch.newtral.org/{archives}/arch-2003
* project: address@hidden/tla--devo--1.1
You can cherry-pick the patch to implement it directly from:
address@hidden/tla--devo--1.1--patch-1
CC List
*******
CC Address | Comment
------------------------------------+-----------------------------
address@hidden |
No files currently attached
For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5644&group_id=4899
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/