bug-gnu-arch
[Top][All Lists]
Advanced

[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: Wed, 19 Nov 2003 15:33:11 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031115 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: Wed 11/19/2003 at 20:33 (GMT)

------------------ Additional Follow-up Comments ----------------------------
Ok, I've coded up a consistency check for library_find, opening another bug 
with it's details.



=================== 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: Wed 11/19/2003 at 20:33       By: robertc
Ok, I've coded up a consistency check for library_find, opening another bug 
with it's details.

-------------------------------------------------------
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/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]