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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: 'arch send' format


From: Martin Pool
Subject: Re: [Gnu-arch-users] Re: 'arch send' format
Date: Sat, 17 Apr 2004 10:10:07 +1000
User-agent: Mutt/1.5.5.1+cvs20040105i

On 16 Apr 2004, Colin Walters <address@hidden> wrote:
> On Fri, 2004-04-16 at 03:39, Martin Pool wrote:
> 
> > I don't think show-changeset can do that very well at the moment, but
> > I don't see any in-principle reason why it could not be extended to do
> > so.
> 
> This has come up several times in the past.

Yes, I thought it probably had.

> That's harder than you think.  The proposals later in this thread like
> "mv foo.c bar.c" or "foo.c => bar.c" are broken.  I actually mentioned
> this in my Grokking Arch presentation.  Arch changesets fundamentally
> operate on file identities, not file names. 

I agree they're broken.  Rather than renames, you need to show ids
before and after.  However just for the benefit of humans, I think it
would be OK to show the renames as "old => new", much as
show-changeset does.

In fact, you need the ids to reliably apply the patch to a tree where
rename/add/deletes have taken place even if the patch itself doesn't
do that.

Rather than solving the hairy rename problems again, I would like just
a lossless text representation of the changeset tarball.  Once it's
decoded, we can just call do-changeset.

I suppose people using things other than arch could do the renames by
hand, taking the responsibility for all the edge cases and conflicts.  

I don't think there is any sense trying to do the renames in a script
in the patch.  It would be like rewriting arch in shell. ;-)

> You can never just pipe this hypothetical export format straight into
> "patch" if you want it to be lossless, because "patch" doesn't
> understand the fact that a file may have moved elsewhere, for example. 
> If a file exists at the old name, it will blithely try to patch it.

I think the social factors of mailing diffs will save us here.

Casual contributors who are likely to send diffs are very unlikely to
rename files.

Upstream maintainers are prepared to fix up patches if they apply to
files which have been renamed.

People still using CVS tend to just not rename files.  For the common
case where there are no renames, using patch is sufficient.

> My worry in providing such an export feature is that people would try to
> use it in a lossless fashion with just patch/mv, and get burnt.

I think the only risk is that people might try to apply it using patch
to an Arch tree and therefore unnecessarily lose information.

I would put a prominent header at the top saying something like this:

  # This is a GNU Arch changeset.
  # 
  # To apply this to an arch project, use "tla unpack-changeset".
  # If you are not using arch, you can apply text changes
  # using GNU Patch, but you may need to correct renames/
  # metadata changes by hand.

--
Martin




reply via email to

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