Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of sebbaz@gmail.com designates
 72.14.220.152 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=V44aqtWNx3Yyb29QS6yQdogDpLptota5rsVTbhDpena5pVSaaUeHAZ+gEOFAWT9QHm
         KAlW2J6deAYclD42VUT1o1bQyDvfmzi2rBzzOY/mG3fasH4Nv5aV/gWHDk+8l5JYR8QA
         BehYozjQBKCy81QCMojy25UdEcDwG4UPOg/Vg=
MIME-Version: 1.0
In-Reply-To: <ded132f10904152251h48d54fbq907231ba094a1cec@mail.gmail.com>
References: <25aac9fc0904150537w6ee52576y749866c67cbeda8c@mail.gmail.com>
	 <ded132f10904150655l66fc7273p4f7d4e14ba93f8d0@mail.gmail.com>
	 <25aac9fc0904150722l3e653d8ek2756a526141b789a@mail.gmail.com>
	 <ded132f10904150824l79cc1075n26e3a86013ae13fa@mail.gmail.com>
	 <25aac9fc0904150920p15405925lfeccc93235f1150f@mail.gmail.com>
	 <ded132f10904152251h48d54fbq907231ba094a1cec@mail.gmail.com>
Date: Thu, 16 Apr 2009 12:09:41 +0100
Message-ID: <25aac9fc0904160409g4194b64fk90ee83e5a7678e24@mail.gmail.com>
Subject: Re: [COMPRESS] Changeset design
From: sebb <sebbaz@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 16/04/2009, Christian Grobmeier <grobmeier@gmail.com> wrote:
> Hi,
>
>
>  >> Did you see ChangeSetTest.testDeletePlusAdd() ?
>  >
>  > Yes.
>  >
>  >>  Is this what you want?
>  >
>  > No, because the delete and add are for different items.
>
>
> I just added testDeletePlusAddSame() and found out that it works like
>  expected (removes file A and adds file B under the same name as file
>  A).

However, it does not work exactly the same as Add then Delete, because
that removes all trace of the Add from the Set.

>  However, this could cause any more trouble if we decide to put the
>  new file on the start of the archive. This is currently not supported.
>

Huh? AFAIK, that is what happens now - adds are processed first.

>
>  >>  > The same problem occurs if one adds a new entry with the same name as
>  >>  > an existing entry. This could be checked, but it is not currently
>  >>  > done.
>  >>
>  >> True. The ChangeSet doesn't check if the same entry is added twice to it.
>  >>  I think the second entry should replace the first.
>  >
>  > This could perhaps be fixed by appropriate choice of equals() implementation
>
>
> Yes good idea. + hashCode, we have discussed it before.
>  When is an ArchiveEntry equal? I think if the name (including any
>  subfolders) and the size is the same.
>

Not sure size is relevant. Most archivers will have problems coping
with multiple entries with the same name.

>
>  >>  A bigger problem is, if one adds an entry whcih allready exists in the stream.
>  >
>  > That's actually what I meant.
>
>
> Ah ok i got you now.
>
>
>  >>  I think the file named A in the ChagneSet should replace the file
>  >>  named A which is allready in the stream.
>  >
>  > Maybe, see below - there are other possible options.
>  >
>
> >>  > Should a file add fail if there is already a matching file, or should
>  >>  > it replace?
>  >>
>  >> Thinking on Windows Explorer, I think it should replace. Or maybe
>  >>  leave this option to the user with an param in ChangeSet? Default =
>  >>  replace, failOnDuplicate() = fail?
>  >
>  > I agree the default should be to replace, but it might be useful to
>  > allow the caller to choose - or at least to know what actually
>  > happened.
>
>
> I agree
>
>
>  >>  > Should a file replace fail if there is no matching file, or should it
>  >>  > be treated as an add?
>  >>
>  >> I think add.
>  >
>  > I agree the default should be add, but it might be useful for the
>  > caller to know whether or not an existing file was replaced.
>
>
> How can he know besides if he chooses what to do?
>

Either an Exception is thrown if the archive was not in the expected
state, or the process() method needs to return a list of what was
actually processed.

>  >>  > Then there is the question of conditional updates based on datestamps.
>  >>
>  >> Does every archive provide datestamps?
>  >
>  > Some do.
>  >
>  > If some don't, then for those one could assume that the exisiting copy is older.
>
>
> OK
>
>  Thanks for your review, i really appreciate it!
>
>
>  Christian
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org