[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn diff output

From: Rob Weir <rweir_at_ertius.org>
Date: 2004-10-05 07:04:59 CEST

[sorry for the late reply]

On Thu, Sep 16, 2004 at 08:30:46AM +0200, Florian Weimer said
> * Russ Allbery:
>
> > This sounds a lot like the thread of conversation that Tom Lord tried to
> > start, way back when, when it was really too early to think about this. I
> > think arch has since come up with a diff format that meets these
> > requirements; maybe that would be a good place to start looking?
>
> The arch changeset format is rather strongly tied to arch semantics.

Well, it's tied to a particular way of looking at changesets, yeah, and
I'd be interested in what other semantics you'd like?

> This means that it doesn't handle copies, just renames, and you need
> some kind of file ID. (You could tack copy support onto it, but you'd
> lose arch compatibility to some extent.)

Hm, what do you want copies to mean in the context of a changeset?

> It's a binary format, and this is the real obstacle IMHO.

Erm, no it's not. It's a directory structure, which is often tar'd and
gzip'd.

> The curious result is that nobody actually sends arch changesets to
> mailing lists, even though they are considered tremendously important
> by the arch community.

No, that the changesets are in seperate files is irrelevant. The
essential point is that they are *conceptually* seperate; you can take
one changeset out of a branch and apply it to others easily. You can
serialise it, compose it, rip it apart and make new ones.

-rob

-- 
Words of the day:    Craig Livingstone covert video Oil deals Manfurov Verisign
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 5 07:06:07 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.