headers
Robert Anderson | 1 Sep 2004 02:15
Picon
Favicon

Re: SOLVED Re: PANIC: duplicate ids in ORIG tree


--- Original Message ---
From: "Georg-W. Koltermann" <Georg.Koltermann <at> mscsoftware.com>
To: Robert Anderson <RWA <at> sbcglobal.net>
CC: Aaron Bentley <abentley <at> panoramicfeedback.com>,
gnu-arch-users <at> gnu.org, Andrew Suffield <asuffield <at> debian.org>
Subject: SOLVED Re: [Gnu-arch-users] PANIC: duplicate ids in ORIG
tree

>It turns out I must have added ids for some ids :( by running "find
>somepath | xargs tla-add" more than once.  At least I ended up
having
>".../somepath/.arch-ids/.arch-ids/...".  Once I rm -r-ed those it
>worked!
>
>Thanks for all your help.

For future reference, you can avoid a lot of trouble by using
"tla inventory" as a "find" replacement, so that you don't
traverse into various control files and directories, which can
cause all kinds of problems.

On the other hand, this seems like it might happen often enough
that there ought to be a safety net for this.  I'm not sure
exactly where it should go, though.

Bob
Permalink | Reply | 1 comment |
headers
Brian May | 1 Sep 2004 01:43
Picon
Picon

Re: PANIC: duplicate ids in ORIG tree

>>>>> "Georg-W" == Georg-W Koltermann <Georg.Koltermann <at> mscsoftware.com> writes:

    Georg-W> I added one file.  I think first I got the PANIC and also
    Georg-W> a message of one new file being unknown so I added it
    Georg-W> hoping the PANIC would go away.  It didn't go away.

In future, it would help if you could quote the exact sequence of
commands you typed and the exact output you got (especially important
given the fact you can't give as the source code).

    Georg-W> There is a post about duplicate ids being possible if one
    Georg-W> was fast eough, see
    Georg-W> http://lists.gnu.org/archive/html/gnu-arch-users/2004-05/msg00596.html

    Georg-W> Do you think I hit that case?  OTOH there don't seem to
    Georg-W> be duplicate ids, per "tla inventory --ids | cut -f2 |
    Georg-W> sort | uniq -d".  Strange.  I think I may need to take a
    Georg-W> look at the source, but not tonight.

I would assume (and hope) that the import operation (or commit
operation) would (should?) abort with an error if duplicate ids exist,
so you don't end up with a corrupt archive.
--

-- 
Brian May <bam <at> snoopy.apana.org.au>
Permalink | Reply | 0 comments |
headers
mlh | 1 Sep 2004 05:06
Picon

Re: SOLVED Re: PANIC: duplicate ids in ORIG tree

On Wed, Sep 01, 2004 at 12:51:19AM +0200, Georg-W. Koltermann wrote:
> It turns out I must have added ids for some ids :( by running "find
> somepath | xargs tla-add" more than once.  At least I ended up having
> ".../somepath/.arch-ids/.arch-ids/...".  Once I rm -r-ed those it
> worked!

I've done this.  It baffled for a while until I found the
problem.  Then I amused myself by adding .arch-ids recursively
until something blew up.

Matt
Permalink | Reply | 0 comments |
headers
Cameron Patrick | 1 Sep 2004 08:28
Picon

Re: SOLVED Re: PANIC: duplicate ids in ORIG tree

Robert Anderson wrote:

> On the other hand, this seems like it might happen often enough
> that there ought to be a safety net for this.  I'm not sure
> exactly where it should go, though.

Adding an id for .arch-ids/ or a file in .arch-ids/ shouldn't be
permitted -- I can't think of a good reason why anyone would want to
do that (although that doesn't mean there isn't one), and it evidently
causes bad things to happen if you aren't careful.

Cameron.
Permalink | Reply | 0 comments |
headers
tomas | 1 Sep 2004 09:33
Picon

Re: Features command for arch

On Tue, Aug 31, 2004 at 04:42:39PM -0400, James Blackwell wrote:

[...]
> Tom Lord wrote:
> > Asking for `features' in `tla' suggests that we suddenly expect *lots*
> > of users to all be running slightly different versions of arch [...]

> What? You don't think that's happening? How many are running 1.1.5?
> 1.2.0? 1.2.1? What about when 1.2.2 comes out?

A friend of KISS myself, I do agree with James here.

As systems become more and more complex, I think it's a responsibility
of developers to ease cross-dependency pressure -- and this feature
thing does help a lot in that. Not only for front-ends, but for all
kinds of user script[let]s.

Hey, even Emacs has `featurep'.

Regards
-- tomás
Permalink | Reply | 0 comments |
headers
Haakon Riiser | 1 Sep 2004 10:30
Picon
Picon

Re: corrupt library (failed inode signature validation)

Matthew,

> Haakon Riiser <hakonrk <at> student.matnat.uio.no> writes:
> 
>> I get this error all the time:
>>
>>   corrupt library (failed inode signature validation)
>>     archive: foo <at> bar--2004
>>     revision: baz--zot--0--patch-100
>>     You should remove this revision from your library.
> 
> Try 'tla library-remove foo <at> bar--2004/baz--zot--0--patch-100' and
> repeat for any other corrupt libraries you find.
> 
> The most likely cause would be if you used 'tla get --link' and then
> used a text editor that doesn't break hardlinks, but maybe a script
> touched the files in your revision library.  Let us know if
> library-remove doesn't fix your problem.

I did not use the --link option and I was already using 1.2.1, so
I'm guessing something else caused the problem.  But thanks for
your and everyone else's suggestions!

By the way, is it OK to also have the working copy on NFS?  Only the
revision library should be on a local filesystem, right?

--

-- 
 Haakon
(Continue reading)

Permalink | Reply | 3 comments |
headers
Cameron Patrick | 1 Sep 2004 10:38
Picon

Re: corrupt library (failed inode signature validation)

Haakon Riiser wrote:

> By the way, is it OK to also have the working copy on NFS?  Only the
> revision library should be on a local filesystem, right?

I'm using that set-up on one machine (/home mounted over NFS) and it
works for me.  But I don't use arch on it very much, so I might just
be lucky.

Cameron.
Permalink | Reply | 0 comments |
headers
Marcus Sundman | 1 Sep 2004 12:19
Picon
Picon
Favicon

Re: Encoding handling proposal

On Tuesday 31 August 2004 01:38, Charles Duffy wrote:
> Anyhow, you ignored the whole thing in my initial post in this thread
> about metadata. Is that because you agree with it, or I'm only echoing
> sentiments that are already adequately fleshed out, or you merely never
> got around to addressing it, or...?

I'm sorry, which post are you referring to? The first one I see is this one: 
http://lists.gnu.org/archive/html/gnu-arch-users/2004-08/msg00759.html

- Marcus Sundman
Permalink | Reply | 3 comments |
headers
Marcus Sundman | 1 Sep 2004 12:46
Picon
Picon
Favicon

Re: Re: Encoding handling proposal

On Monday 30 August 2004 20:34, Stefan Monnier wrote:
> > B) "Content-Type" should be a mandatory metadata string attribute.
>
> In keeping with the "enforce naming convention" policy of Arch, I guess
> that we could just use a mime.types file to map extensions to content
> types.

Such default might be acceptable, but you also need other means. Two files 
with the same extension might have different encodings, e.g. "text/plain; 
charset=utf-8" and "text/plain; charset=iso-8859-1".

> The various type-specific diff algorithms are only ways to optimize
> changeset size and help merging, but they should all work correctly on
> arbitrary binary files.

There are other reasons to use type-specific diff tools, such as the ability 
to actually be able to sensibly compare two OOo Writer documents, or two 
audio files, or two images.

> > D) There should be a filter/plugin architecture to enable a transcoding
> > of files on input and output based on their content-types and user
> > settings and user-provided parameters.
>
> How is a utf-8 going to be transcoded into latin-1 without loss?

1) If all characters in the file belongs to the "latin-1" character 
repertoire then there is no problem.
2) If there is a way to escape characters, such as in java source code, then 
that may be used.
3) If it's OK to use the utf-8 file instead of a "latin-1" file then display
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason McCarty | 1 Sep 2004 14:20
Picon
Favicon

Re: Features command for arch

James Blackwell wrote:
> Tom Lord wrote:
> > Asking for `features' in `tla' suggests that we suddenly expect *lots*
> > of users to all be running slightly different versions of arch, some
> > with such and such feature, some without ---- *AND* ----- we expect
> > that situation to get *so* out of hand that many external tools have
> > to deal [with] all the possible combinations of features.
> 
> What? You don't think that's happening? How many are running 1.1.5?
> 1.2.0? 1.2.1? What about when 1.2.2 comes out?
> [...]
> Sure, we can offload the work to the frontends to track it, but that
> means writing code anyways. The current --version is completely broken
> for this task. With buildcfg -r, you get one version string. With
> buildcfg -r, you get a different string (not a version string at all).
> If you use a tla that comes with a distribution, then it's been screwed
> with in godawful ways.

I have to agree with James; the syntax of about 20 commands changed
between 1.1 and 1.2, and testing --version isn't completely reliable. I
resort to letting the user specify the version, or assume 1.3 when I
can't tell.

--

-- 
Jason McCarty <bclg <at> iup.edu>
Permalink | Reply | 20 comments |

Gmane