You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Eric S. Raymond" <es...@snark.thyrsus.com> on 2004/09/16 15:15:48 UTC
Thoughts and open questions on patch/dump unification
These questions are independent of the action-diff format.
First premise: a dumpfile is an action diff from an empty tree.
In the more general case, an action diff is intended to be applied
to a nonempty tree. An action diff is a list of changesets
("revisions" in current dumpfile terminology).
Attempting to apply an action diff to a repository produces an "action
list" (a list of changesets to be applied to the repository) and an
"exception list" (a list of what changesets cannot be applied).
It is then a policy question whether the action list becomes a commit. If
your policy is very strict, you may permit this only when the
exception list is nonempty. Or, you might want to have a rolling-sync
policy -- apply actions until you hit the first in the exception list,
then stop, But some exceptions are probably harmless: deletion of an
already nonexistent file is the most obvious example.
I don't think the right policy can be decided without implementing
mechanism first and experimenting. The only thing I'm firly sure of
is that partial applications of changesets from the action diff would
be a bad idea. Whoever did the commit that produced that changeset
intended it to be a unit; application diffs should preserve that
property.
Open question: when an action list is applied, should it be merged in
to the repository as a single commit, or as one commit for each
revision in the list? There are arguments both ways. The
commit-per-revision approach preserves the entire history of the
modifications, but possibly at the cost of a lot of clutter. If we go
with the single-commit approach, on the other hand, we'll need to
merge the log messages for each file.
Open question: should applying an action diff always produce a branch?
The biggest advantage of this choice is that repo sync would then
unify with ordinary merge. This would also pretty much settle the
previous question -- the revisions in the action diff would map
straight into commits on the branch it generates.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
The possession of arms by the people is the ultimate warrant
that government governs only with the consent of the governed.
-- Jeff Snyder
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by Andy Whitcroft <ap...@shadowen.org>.
On Friday 17 September 2004 15:51, C. Michael Pilato wrote:
> You wanna talk about kludges? Let's talk about kludges.
> svndumpfilter is kludge. Nice itch, wrong scratch.
I would never suggest that as the right way to do it ... the functionality
however does appear to be where the 'history diff' and what we have in the
dump format which is a 'repository diff' at most. But I am sure I am wasting
nice eggs on granny here :).
-apw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
C. Michael Pilato <cm...@collab.net>:
> You wanna talk about kludges? Let's talk about kludges.
> svndumpfilter is kludge. Nice itch, wrong scratch.
Heh. I had that reaction when I read about svndumpfilter in the book. Nice
to know it's not just me.
> That said, you are correct to say that it is not true that a dumpfile
> must be applied to an empty repository. As you noted, incremental
> dumps (ala 'svnadmin dump -rX:Y --incremental') do not contain a full
> "history diff", or at least that "diff" is not against an empty
> history.
Correction accepted. First premise, revised: A *full* dump can be viewed as
a history diff applied to the empty tree.
Hmmm, the man page hints that running a load against a *nonempty*
repository may actually do the right thing (that is, apply the
revisions in the dummp file to the repo).
If that's true, we're about 80% of the way to repo sync right now! The
remaining issues are packaging, policy, and how we cope with incremental
dumpfiles that don't apply cleanly.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by "C. Michael Pilato" <cm...@collab.net>.
Andy Whitcroft <ap...@shadowen.org> writes:
> On Thursday 16 September 2004 17:33, Eric S. Raymond wrote:
>
> > What I'm talking about, I'll now rename a "history diff". A history
> > diff may consist of one or more action diffs in sequence, each with
> > associated log text, author, and date. History diffs apply to
> > repositories. A dumpfile is a history diff meant to be applied to an
> > empty repository.
>
> This last sentence has been said several times. But with incremental dumps
> don't we actually already do the "history diff" against an existing tree?
> The main part that seems missing is the dumpfilter side of it ie. not
> including changes for the whole repository, just a subset.
You wanna talk about kludges? Let's talk about kludges.
svndumpfilter is kludge. Nice itch, wrong scratch.
That said, you are correct to say that it is not true that a dumpfile
must be applied to an empty repository. As you noted, incremental
dumps (ala 'svnadmin dump -rX:Y --incremental') do not contain a full
"history diff", or at least that "diff" is not against an empty
history.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Andy Whitcroft <ap...@shadowen.org>:
> On Thursday 16 September 2004 17:33, Eric S. Raymond wrote:
> > What I'm talking about, I'll now rename a "history diff". A history
> > diff may consist of one or more action diffs in sequence, each with
> > associated log text, author, and date. History diffs apply to
> > repositories. A dumpfile is a history diff meant to be applied to an
> > empty repository.
>
> This last sentence has been said several times. But with incremental dumps
> don't we actually already do the "history diff" against an existing tree?
> The main part that seems missing is the dumpfilter side of it ie. not
> including changes for the whole repository, just a subset.
Hmmm...can you point me at documentation of this?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by Andy Whitcroft <ap...@shadowen.org>.
On Thursday 16 September 2004 17:33, Eric S. Raymond wrote:
> What I'm talking about, I'll now rename a "history diff". A history
> diff may consist of one or more action diffs in sequence, each with
> associated log text, author, and date. History diffs apply to
> repositories. A dumpfile is a history diff meant to be applied to an
> empty repository.
This last sentence has been said several times. But with incremental dumps
don't we actually already do the "history diff" against an existing tree?
The main part that seems missing is the dumpfilter side of it ie. not
including changes for the whole repository, just a subset.
-apw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by "C. Michael Pilato" <cm...@collab.net>.
"Eric S. Raymond" <es...@thyrsus.com> writes:
> OK. We are talking about two fundamentally different concepts here.
> There is probably a place for both of them in the Subversion universe,
> so I'm going to propose terminology to distinguish them.
*Thank You!*
> You get to keep the term "action diff" for your single-changeset creature
> with no log text, date, or author. An action diff, alone, can only be
> applied to a working copy. Besides change bands in the patch(1) style,
> it may include file adds/renames/deletes. (I'm not clear on whether it
> makes sense for action diffs to include property operations.)
Yes, it does.
> What I'm talking about, I'll now rename a "history diff". A history
> diff may consist of one or more action diffs in sequence, each with
> associated log text, author, and date. History diffs apply to
> repositories. A dumpfile is a history diff meant to be applied to an
> empty repository.
Sounds great.
> To do the decentralized-development thing, action diffs don't suffice.
> We need history diffs. I view the design and implementation of action
> diffs as interesting primarily because it's a building block for doing
> history diffs.
That's correct. Action diffs are *just* 'svn diff' + tree operations
and property changes.
> I hope this clarifies matters.
Quite. Thanks again.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
C. Michael Pilato <cm...@collab.net>:
> Since there is only a single changeset repsented in my concept of an
> "action diff", and it can't even legitimately be called a revision
> (since that exact change may or may not have every been committed --
> at least not as one changeset), then my concept of this "action diff"
> would look just like the *contents* of a single revision chunk from
> the dumpfile format, plus the tweak I mentioned earlier. In other
> words, you'd never even see:
>
> Revision-number: FOO
> ...
>
> It would begin directly with:
>
> Node-path: my/path
> ...
>
> And since there's no revision info, there's no log message, no date,
> no author -- in other words, there's nothing that can't be applied to
> the working copy.
OK. We are talking about two fundamentally different concepts here.
There is probably a place for both of them in the Subversion universe,
so I'm going to propose terminology to distinguish them.
You get to keep the term "action diff" for your single-changeset creature
with no log text, date, or author. An action diff, alone, can only be
applied to a working copy. Besides change bands in the patch(1) style,
it may include file adds/renames/deletes. (I'm not clear on whether it
makes sense for action diffs to include property operations.)
What I'm talking about, I'll now rename a "history diff". A history
diff may consist of one or more action diffs in sequence, each with
associated log text, author, and date. History diffs apply to
repositories. A dumpfile is a history diff meant to be applied to an
empty repository.
To do the decentralized-development thing, action diffs don't suffice.
We need history diffs. I view the design and implementation of action
diffs as interesting primarily because it's a building block for doing
history diffs.
I think it is quite possible that the only format difference between
action and history diffs might be a "commit" element including log
text, date, author, and other metadata. Each commit point would
encompass all action diffs back to the last commit point. Not
by coincidence, dump files already look like this.
I hope this clarifies matters.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by "C. Michael Pilato" <cm...@collab.net>.
"Eric S. Raymond" <es...@thyrsus.com> writes:
> Your view, which is that action diffs apply to working copies, has
> several problems. One is that an action diff and a file dump are now
> two different things with different semantics -- one hacks the repository,
> one the working copy. Another is that you have no good way to handle
> log text in the action diff. If an action diff only changes the working
> copy, where does the log text go?
Since there is only a single changeset repsented in my concept of an
"action diff", and it can't even legitimately be called a revision
(since that exact change may or may not have every been committed --
at least not as one changeset), then my concept of this "action diff"
would look just like the *contents* of a single revision chunk from
the dumpfile format, plus the tweak I mentioned earlier. In other
words, you'd never even see:
Revision-number: FOO
...
It would begin directly with:
Node-path: my/path
...
And since there's no revision info, there's no log message, no date,
no author -- in other words, there's nothing that can't be applied to
the working copy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
C. Michael Pilato <cm...@collab.net>:
> Action diffs aren't applied to repositories. They are applied to
> working copies.
Aha! That's a defensible assumption, but it's not the one I was making.
> Maybe I missed some thread posts, but I thought we were talking about
> a custom patch format for Subversion. Eric, you seem to be thinking
> more about some sort of history replication mechanism which is far
> more involved than just a patch format. Are we on differing planets?
We were. Let's see if we can get back on the same one.
I'm thinking of repo sync as a transaction between repositories that
adds to the the target repository's history, possibly merging in more than
one revision. This is consistent with the first premise: a dumpfile
adds to the history of an empty repository. When you do that, you
don't only get one commit for the whole dumpfile, you get one for each
revision in the dump.
Your view, which is that action diffs apply to working copies, has
several problems. One is that an action diff and a file dump are now
two different things with different semantics -- one hacks the repository,
one the working copy. Another is that you have no good way to handle
log text in the action diff. If an action diff only changes the working
copy, where does the log text go?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by "C. Michael Pilato" <cm...@collab.net>.
"C. Michael Pilato" <cm...@collab.net> writes:
> I have precious little interest in seeing Subversion become a
> decentralized version control system. So "syncing repositories"
> transforms in my mind to "unidirectionally syncing read-only slave
> repositories with a single master repository", and for that purpose
> the existing dump format, as-is, is perfect.
On re-reading my own post, it might sound like a passive attempt at
dissuading further conversion about Eric's greater goal. That's not
the case -- it just isn't my itch. So please, do carry on.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Mark Phippard <Ma...@softlanding.com>:
> The first quote was from cmpilato not me, I am not exactly sure what I
> want.
Sorry for the misunderstanding.
> I mainly want a system exactly like Subversion, it is just that I
> see scenarios where these other needs pop in. When I think of a
> decentralized system, I think of the decentralization extending down to
> the individual prgorammer. What I want is more at the repository level.
Which is how it's normally done in decentralized systems like
BitKeeper, arch, and Aegis. My proposal is influenced by what I know
about all of these systems (and a bit the reverse, too; I had a little
influence on Larry McVoy's thinking back in 1998, and maybe a little on
Peter Miller's thinking in 2000). Thus it's really a rather conservative
proposal; the primitive operations involved in syncing repositories
are fairly well understood.
> I think the main point is that it would probably be hard to do this with
> Subversion as is, but your "history diff" idea could likely make it
> doable.
Yes, I think it would.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2004-09-16 12:56-0400, Mark Phippard wrote:
> "Eric S. Raymond" <es...@thyrsus.com> wrote on 09/16/2004 12:40:17 PM:
> > > > I have precious little interest in seeing Subversion become a
> > > > decentralized version control system. So "syncing repositories"
> > > > transforms in my mind to "unidirectionally syncing read-only slave
> > > > repositories with a single master repository", and for that purpose
> > > > the existing dump format, as-is, is perfect.
> >
>
> The first quote was from cmpilato not me, I am not exactly sure what I
> want. I mainly want a system exactly like Subversion, it is just that I
> see scenarios where these other needs pop in. When I think of a
> decentralized system, I think of the decentralization extending down to
> the individual prgorammer. What I want is more at the repository level.
Same here, and at the mean time when we don't have that, I would like
to see a svn commit/update, which is capable to do following:
You can have two URLs in your working copy, one for read-only
actions, one for write actions.
Now you could do your checkout from your local slave, and when you are
up to time to commit you will do it against master. If your commit
ended to be an out-of-date conflict (which isn't presented at the slave),
you could have a switch for update to tell that it should do off-cache
update directly from master.
The master could distribute changes to the slaves by using incremental
dumps (or using FSFS and rsync?). This infastructure is presented at
the moment. And needs only little supportive scripting in post-commit
hooks.
It is true that you won't get truly distributed system that way, but
you still will win something:
- Load on your master will be smaller
- you could divide your team between distances and use thin and/or
expensive network connection between them.
- If you lose your connection to the master, you still could see logs,
diff against previous versions etc.
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Dave Rolsky wrote:
>>in a cleaner way. At the very least I'd be happier if the svk-equivalent
>>stuff were in Python, which I think has better long-term maintainability.
>
>
> So basically you have no meaningful criticism here, you just want to start
> a language war. Good idea. Then we can fight about emacs vs. vim
> afterwards!
>
> Seriously, _you_ might be happier if it were in Python, but other people
> wouldn't be. Who cares? Unless you plan to write an SVK-alike in Python
> what's the point of bringing this up?
+1
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by kf...@collab.net.
I know, let's have a war about whether or not we're having a language
war! :-)
Seriously, this discussion has been so productive up till now; let's
please drop the Perl/Python meta-discussion, and go back to discussing
extended patch formats and learning from SVK's features.
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by Max Bowsher <ma...@ukf.net>.
Eric S. Raymond wrote:
> I feel a need, at this point, to observe that I am *not* the person who
> brought up the merits or demerits of Perl as an svk issue.
You did say:
>>> I think svk is a clever idea, but I would prefer to see support for
>>> decentralized development integrated into the subversion core and done
>>> in a cleaner way. At the very least I'd be happier if the
>>> svk-equivalent
>>> stuff were in Python, which I think has better long-term
>>> maintainability.
Dave Rolsky replied:
>> So basically you have no meaningful criticism here, you just want to
>> start
>> a language war. Good idea. Then we can fight about emacs vs. vim
>> afterwards!
>>
>> Seriously, _you_ might be happier if it were in Python, but other people
>> wouldn't be. Who cares? Unless you plan to write an SVK-alike in Python
>> what's the point of bringing this up?
Eric S. Raymond wrote:
> So to those
> of you who accused me of wanting to start a language war, kindly get
> stuffed.
Dave's rebuke was a little confrontational. But it does contain a valid
statement - unless you are planning to rewrite SVK in Python, what was the
point of mentioning Python at all here?
Discussing relative maintainability is somewhat irrelevant when one
implementation exists and the other does not.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Max Bowsher <ma...@ukf.net>:
> >>Although (IMO) it's easier to write unmaintainable code in Perl, it's
> >>possible to write Perl which is just as maintainable as Python, given a
> >>bit of discipline.
> >
> >I suspect it's also possible to write Python which is just as
> >unmaintainable as Perl, given a lack of discipline ;)
>
> Yes, that's probably true ;-)
I feel a need, at this point, to observe that I am *not* the person who
brought up the merits or demerits of Perl as an svk issue. So to those
of you who accused me of wanting to start a language war, kindly get
stuffed.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by Max Bowsher <ma...@ukf.net>.
Dave Rolsky wrote:
> On Fri, 17 Sep 2004, Max Bowsher wrote:
>
>>> Storing merge history will be in the subversion core in the future,
>>> according to the project's todo list. But the developers have been
>>> pretty
>>> clear that decentralized version control is not one of the their main
>>> goals.
>>
>> Correct - but "not a main goal" is not the same as "go away, we don't
>> want
>> it even if well designed and coded". I'm only 1 opinion, but I don't see
>> any
>> reason why certain core svk-alike features couldn't migrate into
>> subversion
>> itself eventually.
>
> Agreed on the first point. On the second, the only problem there is that
> SVK is moving at an incredibly fast pace. Porting its feature set to
> Subversion would require catching up with it and writing all that code in
> C. C is not known for its quick development speed ;)
Indeed. Note that I said "certain core features" :-)
Let me take this moment to say that I think SVK is incredibly good for SVN,
in that it provides a breeding ground for exciting new designs for the
future.
> But I'd imagine that if someone did the work, the core developers would
> take a serious look at incorporating it. I just don't know that
> convincing them to do it themselves is possible.
Unlikely, even just the medium term goals from
http://subversion.tigris.org/roadmap.html should keep them busy for quite
some time.
> On the subject of a more comprehensive patch format that applies to trees,
> that certainly seems like a useful thing.
Indeed, the basic need for "svn patch" has been lying around in the issue
tracker for years. http://subversion.tigris.org/issues/show_bug.cgi?id=511
>> Although (IMO) it's easier to write unmaintainable code in Perl, it's
>> possible to write Perl which is just as maintainable as Python, given a
>> bit
>> of discipline.
>
> I suspect it's also possible to write Python which is just as
> unmaintainable as Perl, given a lack of discipline ;)
Yes, that's probably true ;-)
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by Dave Rolsky <au...@urth.org>.
On Fri, 17 Sep 2004, Max Bowsher wrote:
> > Storing merge history will be in the subversion core in the future,
> > according to the project's todo list. But the developers have been pretty
> > clear that decentralized version control is not one of the their main
> > goals.
>
> Correct - but "not a main goal" is not the same as "go away, we don't want
> it even if well designed and coded". I'm only 1 opinion, but I don't see any
> reason why certain core svk-alike features couldn't migrate into subversion
> itself eventually.
Agreed on the first point. On the second, the only problem there is that
SVK is moving at an incredibly fast pace. Porting its feature set to
Subversion would require catching up with it and writing all that code in
C. C is not known for its quick development speed ;)
But I'd imagine that if someone did the work, the core developers would
take a serious look at incorporating it. I just don't know that
convincing them to do it themselves is possible.
On the subject of a more comprehensive patch format that applies to trees,
that certainly seems like a useful thing.
> Although (IMO) it's easier to write unmaintainable code in Perl, it's
> possible to write Perl which is just as maintainable as Python, given a bit
> of discipline.
I suspect it's also possible to write Python which is just as
unmaintainable as Perl, given a lack of discipline ;)
-dave
/*===========================
VegGuide.Org
Your guide to all that's veg.
===========================*/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by Max Bowsher <ma...@ukf.net>.
Dave Rolsky wrote:
> On Thu, 16 Sep 2004, Eric S. Raymond wrote:
>
>> John Peacock <jp...@rowman.com>:
>>> Is this a subtle bias because
>>> it is written in Perl using the Perl bindings to Subversion or a more
>>> direct criticism of the use of custom attributes to store merge points?
>>
>> I can't speak for anyone else here, but I regard both those traits
>> as being kludgy.
>>
>> I think svk is a clever idea, but I would prefer to see support for
>> decentralized development integrated into the subversion core and done
>
> I don't really see this as terribly likely.
>
> Storing merge history will be in the subversion core in the future,
> according to the project's todo list. But the developers have been pretty
> clear that decentralized version control is not one of the their main
> goals.
Correct - but "not a main goal" is not the same as "go away, we don't want
it even if well designed and coded". I'm only 1 opinion, but I don't see any
reason why certain core svk-alike features couldn't migrate into subversion
itself eventually.
>> in a cleaner way. At the very least I'd be happier if the svk-equivalent
>> stuff were in Python, which I think has better long-term maintainability.
>
> So basically you have no meaningful criticism here, you just want to start
> a language war. Good idea. Then we can fight about emacs vs. vim
> afterwards!
>
> Seriously, _you_ might be happier if it were in Python, but other people
> wouldn't be. Who cares? Unless you plan to write an SVK-alike in Python
> what's the point of bringing this up?
Well said.
Although (IMO) it's easier to write unmaintainable code in Perl, it's
possible to write Perl which is just as maintainable as Python, given a bit
of discipline.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by Dave Rolsky <au...@urth.org>.
On Thu, 16 Sep 2004, Eric S. Raymond wrote:
> John Peacock <jp...@rowman.com>:
> > Is this a subtle bias because
> > it is written in Perl using the Perl bindings to Subversion or a more
> > direct criticism of the use of custom attributes to store merge points?
>
> I can't speak for anyone else here, but I regard both those traits
> as being kludgy.
>
> I think svk is a clever idea, but I would prefer to see support for
> decentralized development integrated into the subversion core and done
I don't really see this as terribly likely.
Storing merge history will be in the subversion core in the future,
according to the project's todo list. But the developers have been pretty
clear that decentralized version control is not one of the their main
goals.
> in a cleaner way. At the very least I'd be happier if the svk-equivalent
> stuff were in Python, which I think has better long-term maintainability.
So basically you have no meaningful criticism here, you just want to start
a language war. Good idea. Then we can fight about emacs vs. vim
afterwards!
Seriously, _you_ might be happier if it were in Python, but other people
wouldn't be. Who cares? Unless you plan to write an SVK-alike in Python
what's the point of bringing this up?
-dave
/*===========================
VegGuide.Org
Your guide to all that's veg.
===========================*/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
John Peacock <jp...@rowman.com>:
> Is this a subtle bias because
> it is written in Perl using the Perl bindings to Subversion or a more
> direct criticism of the use of custom attributes to store merge points?
I can't speak for anyone else here, but I regard both those traits
as being kludgy.
I think svk is a clever idea, but I would prefer to see support for
decentralized development integrated into the subversion core and done
in a cleaner way. At the very least I'd be happier if the svk-equivalent
stuff were in Python, which I think has better long-term maintainability.
I am not a core svn maintainer, so don't take my objections as gospel.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by John Peacock <jp...@rowman.com>.
Eric S. Raymond wrote:
> Your "place to commit" should be a local repository, and your way
> of shipping fully-baked EBCDIC changes to the main project should
> be *exactly* the kind of repo sync I have been attempting to describe.
Which is exactly what SVK already does, so rather than trying to reinvent the
wheel, why not look at what CLKao has already accomplished and see about moving
that into the Subversion core. I don't share your (Eric's) opinion that svk is
a kludge, but that may be because I am actually using it on an almost daily
basis to great effect. Is this a subtle bias because it is written in Perl
using the Perl bindings to Subversion or a more direct criticism of the use of
custom attributes to store merge points?
Oh, and the Win32 port is apparently complete and passing all existing tests:
http://svk.elixus.org/index.cgi?SVKWin32
I'll be testing that RSN, since I want to move off of CVSNT for work...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by Mark Phippard <Ma...@softlanding.com>.
"Eric S. Raymond" <es...@thyrsus.com> wrote on 09/16/2004 12:40:17 PM:
> Mark Phippard <Ma...@softlanding.com>:
> > > I have precious little interest in seeing Subversion become a
> > > decentralized version control system. So "syncing repositories"
> > > transforms in my mind to "unidirectionally syncing read-only slave
> > > repositories with a single master repository", and for that purpose
> > > the existing dump format, as-is, is perfect.
>
> > Obviously our main problem currently is that we are essentially doing
a
> > lot of work without any version control because we have no place to
> > commit. All we can do currently is make patches on a regular basis
and
> > archive them. Yes, we could solve the problem by having an EBCDIC
branch
> > in the actual repository, but lets just assume that is not an option.
>
> Heh. First you say you have little interest in seeing Subversion
> become a decentralized version control system. then you present a use
> case that really wants exactly that.
>
The first quote was from cmpilato not me, I am not exactly sure what I
want. I mainly want a system exactly like Subversion, it is just that I
see scenarios where these other needs pop in. When I think of a
decentralized system, I think of the decentralization extending down to
the individual prgorammer. What I want is more at the repository level.
In other words, there are the central Subversion, TortoiseSVN and
Subclipse repositories with hundreds of programmers working with them, and
there is my repository which can pull in changes from those repositories,
but otherwise serves a pool of programmers on my end. From the point of
view of the programmers on my end they are using Subversion like anyone
else would -- against a central repository. It is just that there is this
"virtual programmer" that is also updating an area of our repository by
pulling in changes from other repositories and applying them.
It isn't something I have tried to solve yet because I do not know if it
is a long term problem for me. But to return to my scenario suppose it is
decided that the EBCDIC port isn't worth polluting the trunk with, and I
couldn't get my own branch for it, then this is something I would want to
solve. Similarly, maybe we want to contribute the EBCDIC port but still
maintain our own custom private version with some specific hacks that
Subversion itself wouldn't want in the main tree. I could see the need
for something like this over the long term.
I think the main point is that it would probably be hard to do this with
Subversion as is, but your "history diff" idea could likely make it
doable.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Mark Phippard <Ma...@softlanding.com>:
> > I have precious little interest in seeing Subversion become a
> > decentralized version control system. So "syncing repositories"
> > transforms in my mind to "unidirectionally syncing read-only slave
> > repositories with a single master repository", and for that purpose
> > the existing dump format, as-is, is perfect.
> Obviously our main problem currently is that we are essentially doing a
> lot of work without any version control because we have no place to
> commit. All we can do currently is make patches on a regular basis and
> archive them. Yes, we could solve the problem by having an EBCDIC branch
> in the actual repository, but lets just assume that is not an option.
Heh. First you say you have little interest in seeing Subversion
become a decentralized version control system. then you present a use
case that really wants exactly that.
Your "place to commit" should be a local repository, and your way
of shipping fully-baked EBCDIC changes to the main project should
be *exactly* the kind of repo sync I have been attempting to describe.
IMHO...
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by Andy Whitcroft <ap...@shadowen.org>.
On Thursday 16 September 2004 17:05, Mark Phippard wrote:
> We work on Windows so svk is not an option. How could we do something
> like this? It sounds like this new proposal would be able to solve
> problems like this.
You might want to check back with the svk people, I think the next release
will be for windows too. Cirtainly a windows port was merged with trunk in
the last two days or so ....
-apw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Thursday 16 September 2004 18:05, Mark Phippard wrote:
> We work on Windows so svk is not an option.
Have a look at
http://svk.elixus.org/?SVKWin32
There is an
http://wagner.elixus.org/~autrijus/win32.3/svk.exe
which is a standalone-binary that runs on windows ...
It has an perl interpreter and all files included in itself, which are
unpacked on the first run.
But it works good, so far as I have tested ...
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by Mark Phippard <Ma...@softlanding.com>.
cmpilato@localhost.localdomain wrote on 09/16/2004 11:50:34 AM:
> Mark Phippard <Ma...@softlanding.com> writes:
>
> > I started to write a similar reply as I was also thinking of this as
> > a patch you would apply to a WC then you would just resolve
> > conflicts and commit as normal. However, I then recalled Eric did
> > mention previously that he saw this as a way of synching
> > repositories.
>
> Hm.
>
> I have precious little interest in seeing Subversion become a
> decentralized version control system. So "syncing repositories"
> transforms in my mind to "unidirectionally syncing read-only slave
> repositories with a single master repository", and for that purpose
> the existing dump format, as-is, is perfect.
Let me pose a scenario to you, part real, part hypothetical. I will
confess that I have not looked for a way to solve this yet, so it may be
doable already with what Subversion offers.
We are working on porting Subversion to OS/400, which is EBCDIC based
(which I mention because that is where the majority of the work lies). The
port is a fairly substantial amount of work over a fairly substantial
amount of time. We have our WC attached to the Subversion repository and
the 1.1.x branch so that we can keep synched up with changes. Eventually,
we obviously want to be able to submit this back as a patch.
We have not had to do anything with TortoiseSVN or Subclipse, and are not
likely to, but lets just say we did to complicate it a bit more as they
are in different repositories.
Ideally, we could have our own Subversion repository that mirrored trunk
or branches from these repositories. We could then make branches within
our repository for our port and use regular Subversion features to update
our branch from the main branch as it is updated with the master
repository, as well as commit from our WC.
We work on Windows so svk is not an option. How could we do something
like this? It sounds like this new proposal would be able to solve
problems like this.
Obviously our main problem currently is that we are essentially doing a
lot of work without any version control because we have no place to
commit. All we can do currently is make patches on a regular basis and
archive them. Yes, we could solve the problem by having an EBCDIC branch
in the actual repository, but lets just assume that is not an option.
Thanks
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard <Ma...@softlanding.com> writes:
> I started to write a similar reply as I was also thinking of this as
> a patch you would apply to a WC then you would just resolve
> conflicts and commit as normal. However, I then recalled Eric did
> mention previously that he saw this as a way of synching
> repositories.
Hm.
I have precious little interest in seeing Subversion become a
decentralized version control system. So "syncing repositories"
transforms in my mind to "unidirectionally syncing read-only slave
repositories with a single master repository", and for that purpose
the existing dump format, as-is, is perfect.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by Mark Phippard <Ma...@softlanding.com>.
cmpilato@localhost.localdomain wrote on 09/16/2004 11:28:22 AM:
> > It is then a policy question whether the action list becomes a
> > commit.
>
> Nope.
>
> And from here, it's obvious that you and I have such differing ideas
> on what we're working on here that further response will only add
> confusion. :-)
>
> Maybe I missed some thread posts, but I thought we were talking about
> a custom patch format for Subversion. Eric, you seem to be thinking
> more about some sort of history replication mechanism which is far
> more involved than just a patch format. Are we on differing planets?
I started to write a similar reply as I was also thinking of this as a
patch you would apply to a WC then you would just resolve conflicts and
commit as normal. However, I then recalled Eric did mention previously
that he saw this as a way of synching repositories. For example:
http://www.contactor.se/~dast/svn/archive-2004-09/0472.shtml
Probably worth exploring his ideas on that as well as the apply to WC
scenario.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Thoughts and open questions on patch/dump unification
Posted by "C. Michael Pilato" <cm...@collab.net>.
"Eric S. Raymond" <es...@snark.thyrsus.com> writes:
> These questions are independent of the action-diff format.
>
> First premise: a dumpfile is an action diff from an empty tree.
Yes.
> In the more general case, an action diff is intended to be applied
> to a nonempty tree.
Yes.
> An action diff is a list of changesets ("revisions" in current
> dumpfile terminology).
If "action diff" is the terminology we're using to talk about the
newfangled output from 'svn diff', then No. An action diff (by that
definition) is the single changeset that results from concatenating
many changesets.
> Attempting to apply an action diff to a repository produces an "action
> list" (a list of changesets to be applied to the repository) and an
> "exception list" (a list of what changesets cannot be applied).
Action diffs aren't applied to repositories. They are applied to
working copies.
> It is then a policy question whether the action list becomes a
> commit.
Nope.
And from here, it's obvious that you and I have such differing ideas
on what we're working on here that further response will only add
confusion. :-)
Maybe I missed some thread posts, but I thought we were talking about
a custom patch format for Subversion. Eric, you seem to be thinking
more about some sort of history replication mechanism which is far
more involved than just a patch format. Are we on differing planets?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org