Re: [Gnu-arch-users] tag'ged (branched) and cacherev'ed archive dependency?

[Rodrigo Bernardo Pimentel]

On Fri, Feb 20 2004 at 03:04:43AM BRT, Cameron Patrick <address@hidden> wrote:
> Rodrigo Bernardo Pimentel wrote:
> 
> |         Hmmm... True, it doesn't. Do I have to cacherev
> | address@hidden/zzbot--devel--0.1, is that it?
> 
> Probably.  (Unless there's something else going wrong too - that's
> always a possibility...)

        Well, that might be, then, because I cachereved in the mirror (and
checked, the .tar.gz is there), but I still get the same error:

address@hidden:~/prog/zzbot$ tla cacherev 
address@hidden/zzbot--devel--0.1--patch-2
address@hidden's password:
* from archive cached: address@hidden/zzbot--devel--0.1--base-0
* patching for revision: address@hidden/zzbot--devel--0.1--patch-1
* patching for revision: address@hidden/zzbot--devel--0.1--patch-2
address@hidden:~/prog/zzbot$

        As you can see, base-0 was already cached. One way or the other,
patch-2 is at the mirror:

./zzbot/zzbot--devel/zzbot--devel--0.1/patch-2/zzbot--devel--0.1--patch-2.tar.gz

        I try again, and:

address@hidden:~$ tla archives
address@hidden
    http://isnomore.net/arch/public
address@hidden:~$ tla get address@hidden/zzbot--devel--0.1 zzbot
archive not registered: address@hidden
  (see register-archive)
address@hidden:~$

        Any ideas? :(

> | Shouldn't archive-mirror do that for me?
> 
> It'll only do it for you if the revision was cached when cacherev copied
> it the first time.  If you e.g. commit a revision, mirror it, then cache
> it, the mirror won't have the cached version.  On the other hand, if you
> commit, cache, then mirror, the mirror /will/ have the cacherev.

        Ah, I see... I'll try it later, when I have something else to
commit. Thanks!

> | > That said, deleting the old archive is a generally bad idea, as you lose
> | > access to the detailed history.
> | 
> |         I noticed that, I'll probably keep it somewhere. But, again,
> | shouldn't cacherev include the detailed history for the projects in
> | question?
> 
> Why should it?  It's primarily there for performance reasons, to make it
> faster to check out a revision than downloading the initial version and
> apply every patch since the dawn of time.  If you want the history, you
> can check out the /other/ revisions.  (The cacherev will still contain
> all of the commit logs from previous revisions but not the actual
> contents of the changesets.)

        But that means I can't migrate a project from one archive to another
and deactivate the older one, for whatever reason, without losing
information, doesn't it? Or, think of the situation above (if I could get
the project I'm trying to :p). I know I could mirror the old, deactivated
archive in a publicly accessible place, but it seems like a hack, a
workaround, not like a real solution. What if I deactivated the archive
because I had private and public projects mixed, there? There are ways
around it, but it gets uglier and uglier, for something that should be
simple.


> | Sometimes you just have to erase an archive (say, you'll have to
> | format the machine, or you find out you made a mess out of it, or your
> | hard drive crashes and you simply lose it all)...
> 
> Protecting against a lack of backups is not what cacherevs are for.  If
> the archive is important to you, keep mirrors of it in several locations.

        I was just making up examples. Let's try a better one: say I tag a
project of yours in an archive of mine, and start to work on it. Then you
decide you don't want to keep that archive up and simply delete it, without
telling me first (perhaps you don't even know I had tagged it). Even if I
had it cached, I'd lose all history information before my tag. Is this how
it's supposed to work?

        The tutorial at http://regexps.srparish.net/tutorial-tla/arch.html
indicates otherwise:

"The question then arises: what if Alice and Bob's archive "goes away"? As
things stand, if that happens, Candice will no longer be able to get  from
her branch."

        True, it doesn't mention history at all, but it raises the concern
of (possibly forever) unaccessible archives and the need to safeguard your
branch against it. Since history is an important component of a project, it
seems to me that not saving it (not even allowing to) is a serious
deficiency.


        Thanks,



                rbp
-- 
 Rodrigo Bernardo Pimentel                         <address@hidden>
 http://isnomore.net                          GPG KeyId: <0x0DB14978>

This isn't right. This isn't even wrong!
          -- Wolfgang Pauli