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 18:48:23 UTC
Eric goes to lunch -- a decentralized-development user story
One of the best organizing ideas for thinking about software design
I've learned about in the last ten years is also one of the simplest,
It's designing by user stories -- laying out the things real users
want to do in real situations.
So I'm going to tell a user story about what I want to be able to do
with Subversion, and encourage you all to think about it as we
continue to discuss action diffs and history diffs and other
impedimenta. Everything in this story, other than one hypothetical
Subversion feature, is true. Think of it as science fiction.
--------------------------------------------------------------------
Eric goes to lunch
Eric is working on a project called gpsd, a service daemon that
monitors a serial or USB port with a GPS attached to it and
republishes the results on a well-known TCP/IP port where multiple
applications can get at it without contending for the GPS port.
The gpsd project lives at berlios.de, a hosting site Eric chose
specifically because it offers Subversion. Most of the time Eric
writes code on his desktop machine. The desktop machine has a
broadband connection and can always reach berlios.de.
Sometimes Eric uses his laptop, which has wireless hardware. When he
is at home, it can talk to the 80211b access point in Eric's
basement, and also reach berlios.de.
Eric likes to eat lunch at a sandwich shop that's an easy bike trip
from his house. It's a good place, run by a couple of Greeks who
greet Eric by name and tend to put a little extra meat in his hoagies.
Eric often spends a leisurely early afternoon there, hacking on his laptop.
Alas, the nice little sandwich shop has no wireless. Before
Subversion had repository sync, Eric couldn't do commits while eating
lunch. This was frustrating; he had to litter his working directory
with copies of checkpoint files (in case a change turned out to be
bad) and defer commits until he got home.
Now things are better. Before bicycling to lunch, Eric ran a one-line
shellscript that uses rsync to update a local copy of the gpsd
repository on his laptop:
rsync http://svn.berlios.de/svnroot/gpsd ~/svn/gpsd/SVN
As he eats lunch, he does commits to that local repository. When he
gets within range of his wireless net again, he runs another one-line
shellscript from within his working-copy directory that does this:
svn sync http://svn.berlios.de/svnroot/gpsd
This ships all the commits he did over lunch to the repo in Germany.
Then he closes his laptop, sits down at his desk, and types "svn
update" at the keyboard of his desktop machine.
Seconds later, his desktop working copy is updated. Eric continues
hacking.
--------------------------------------------------------------------
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
You need only reflect that one of the best ways to get yourself a
reputation as a dangerous citizen these days is to go about repeating
the very phrases which our founding fathers used in the great struggle
for independence. -- Attributed to Charles Austin Beard (1874-1948)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Eric goes to lunch -- a decentralized-development user story
Posted by Barry Scott <ba...@barrys-emacs.org>.
On Sep 18, 2004, at 21:18, John Peacock wrote:
I'll stop arguing about language. I'll not convince you and you will
not convince me.
> I think CLKao would agree that he would be perfectly happy to have all
> of the existing functionality in svk transferred into the Subversion
> core (where it would be C, not Python). The "design you throw away"
> need bear no substantial relation to the eventual package with the
> same functional capabilities.
Give svk an API that I can access without parsing the text output and
it becomes interesting, in my opinion.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Eric goes to lunch -- a decentralized-development user story
Posted by John Peacock <jp...@rowman.com>.
Barry Scott wrote:
>
> I do not think its a good idea to have important subsystems only be
> driven by parsing text output of a program.
The front page of the Subversion page at Tigris directly contradicts you:
> # Parseable output
>
> All output of the Subversion command-line client is carefully designed to be both human readable and automatically parseable; scriptability is a high priority.
WinCVS is an excellent example of making silk purses out of sows ears; CVS had
no other interface so a GUI was written to drive the commandline. I wasn't
saying that this would be the best way to interface with svk, merely that the
fact that svk is only commandline now is in no way relevant to the difficulty of
making a gui for it.
> I know lots of people like Perl, I'm not one of them. Its far to hard to
> maintain and difficult to learn.
> Languages like Python are far better designed.
Both of those statements are value laden and should really be prefixed with "I
believe" since neither of them are objective facts. Your personal opinion is
interesting, but hardly relevant to the discussion, which is how an existing
tool already performs all of the functionality that was requested. What
language that tool is written in is, truly, unimportant. Please try and keep
your personal biases out of the discussion; we don't need a language war here.
I think CLKao would agree that he would be perfectly happy to have all of the
existing functionality in svk transferred into the Subversion core (where it
would be C, not Python). The "design you throw away" need bear no substantial
relation to the eventual package with the same functional capabilities.
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: Eric goes to lunch -- a decentralized-development user story
Posted by Barry Scott <ba...@barrys-emacs.org>.
On Sep 17, 2004, at 02:10, John Peacock wrote:
> Barry Scott wrote:
>> But svk is not usable outside of the command line so its no use to
>> folks that want a GUI.
>
> That's an unusual assertion, seeing that the WinCVS GUI works by
> driving the commandline CVSNT client. Just because right now no one
> has bothered to produce a GUI for svk doesn't mean it isn't possible.
> It's just not important right now.
I do not think its a good idea to have important subsystems only be
driven by parsing text output of a program.
Its great that SVN has an API that can be driven without the need to
parse output in a range of languages.
If svk has the same computer API its ready for prime time tool use.
>> And you force Perl on them as well.
>
> That's a fairly loaded statement there; a suprisingly large number of
> people like Perl just fine, thanks.
I know lots of people like Perl, I'm not one of them. Its far to hard
to maintain and difficult to learn.
Languages like Python are far better designed.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Eric goes to lunch -- a decentralized-development user story
Posted by John Peacock <jp...@rowman.com>.
Barry Scott wrote:
> But svk is not usable outside of the command line so its no use to folks
> that want a GUI.
That's an unusual assertion, seeing that the WinCVS GUI works by driving the
commandline CVSNT client. Just because right now no one has bothered to produce
a GUI for svk doesn't mean it isn't possible. It's just not important right now.
> And you force Perl on them as well.
That's a fairly loaded statement there; a suprisingly large number of people
like Perl just fine, thanks.
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: Eric goes to lunch -- a decentralized-development user story
Posted by Barry Scott <ba...@barrys-emacs.org>.
But svk is not usable outside of the command line so its no use to
folks that want a GUI.
And you force Perl on them as well.
Barry
On Sep 16, 2004, at 20:41, John Peacock wrote:
> Eric S. Raymond wrote:
>> Now things are better. Before bicycling to lunch, Eric ran a one-line
>> shellscript that uses rsync to update a local copy of the gpsd
>> repository on his laptop:
>> rsync http://svn.berlios.de/svnroot/gpsd ~/svn/gpsd/SVN
>
> [first time only]
>
> svk mirror //gpsd/trunk http://svn.berlios.de/svnroot/gpsd
> svk cp //gpsd/trunk //gpsd/local/trunk
>
> [every other time, get up-to-date changes]
>
> svk sync //gpsd/trunk
>
> [check for conflicts]
>
> svk smerge -C //gpsd/trunk //gpsd/local/trunk
>
> [and automatically merge if no conflicts]
>
> svk smerge //gpsd/trunk //gpsd/local/trunk
>
>> As he eats lunch, he does commits to that local repository. When he
>> gets within range of his wireless net again, he runs another one-line
>> shellscript from within his working-copy directory that does this:
>> svn sync http://svn.berlios.de/svnroot/gpsd
>
> svk smerge -C //gpsd/local/trunk //gpsd/trunk
> svk smerge //gpsd/local/trunk //gpsd/trunk
> svk sync //gpsd/local/trunk
>
>> This ships all the commits he did over lunch to the repo in Germany.
>> Then he closes his laptop, sits down at his desk, and types "svn
>> update" at the keyboard of his desktop machine.
>
> Sure, it is a few extra lines, but there is already a way to do
> _exactly_ what you want. Since this is your own repository, you can
> even skip the local/trunk and do all of your work in the mirrored
> location itself and the sync will do the right thing when you are
> reconnected.
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Eric goes to lunch -- a decentralized-development user story
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
John Peacock <jp...@rowman.com>:
> Sure, it is a few extra lines, but there is already a way to do _exactly_
> what you want. Since this is your own repository, you can even skip the
> local/trunk and do all of your work in the mirrored location itself and the
> sync will do the right thing when you are reconnected.
OK, I'll admit that's pretty impressive.
However, I am not going to pronounce on the relationship between svn and
svk. I'm not a principal of either project, so it's not my place to do so.
I will cautiously suggest that some sort of investigation of a possible
merger might be in order.
I don't care a lot about how "Eric goes to lunch" comes true. I've explained
why I think svk's approach is a bit kludgy. But perhaps we should be viewing
svk as a prototype for features that can live in the svn core.
And now I'll shut up.
--
<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: Eric goes to lunch -- a decentralized-development user story
Posted by John Peacock <jp...@rowman.com>.
Eric S. Raymond wrote:
> Now things are better. Before bicycling to lunch, Eric ran a one-line
> shellscript that uses rsync to update a local copy of the gpsd
> repository on his laptop:
>
> rsync http://svn.berlios.de/svnroot/gpsd ~/svn/gpsd/SVN
[first time only]
svk mirror //gpsd/trunk http://svn.berlios.de/svnroot/gpsd
svk cp //gpsd/trunk //gpsd/local/trunk
[every other time, get up-to-date changes]
svk sync //gpsd/trunk
[check for conflicts]
svk smerge -C //gpsd/trunk //gpsd/local/trunk
[and automatically merge if no conflicts]
svk smerge //gpsd/trunk //gpsd/local/trunk
>
> As he eats lunch, he does commits to that local repository. When he
> gets within range of his wireless net again, he runs another one-line
> shellscript from within his working-copy directory that does this:
>
> svn sync http://svn.berlios.de/svnroot/gpsd
svk smerge -C //gpsd/local/trunk //gpsd/trunk
svk smerge //gpsd/local/trunk //gpsd/trunk
svk sync //gpsd/local/trunk
>
> This ships all the commits he did over lunch to the repo in Germany.
> Then he closes his laptop, sits down at his desk, and types "svn
> update" at the keyboard of his desktop machine.
>
Sure, it is a few extra lines, but there is already a way to do _exactly_ what
you want. Since this is your own repository, you can even skip the local/trunk
and do all of your work in the mirrored location itself and the sync will do the
right thing when you are reconnected.
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: Eric goes to lunch -- a decentralized-development user story
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
On Fri 2004-09-17 at 02:59:50 +0200, Benjamin wrote:
> But to come back to my original question: If you see a reason why a
> more or less sophisticated patch management support wouldn't suffice
> for you, I would love to hear it (more than any specific critic to the
> details of implementation I just have come up with).
One more thing: I wouldn't have a problem with the patch management[1]
using a local repository for storing and diff'ing its stuff. It's just
that a local repo doesn't automatically offer what I understand as
patch management support[2]
My suggestion came from the background that I think doing local repo
support _well_ is harder than the patch management I suggested. If
that premise is wrong, my point is moot (because a local repo offers
more flexibility, I think).
Bye,
Benjamin.
[1] Since I am throwing that expression around, I thought I do a
little clarification. I haven't thought this out fully and am not
sure that I can come up with a complete list, but what I would
expect at least is:
1. easy saving of patches (for re-applying or commiting)
2. easy editing of patches (can be via an apply-edit-save cycle)
3. easy overview of pending patches
4. easy commiting of patches (ideally, if there are no conflicts, all
local changes are committed in one pass)
5. easy discarding of patches
6. easy updates (in order to commit or keep current with parallel
development)
7. easy way to export patches (in order to send them in per email)
AFAICS, a local repo, without further integration, mainly lacks
for doing #2, #5 and #6.
[2] Although it would be doable to do integration in a way that it is
equally useful for patch management. Eric, your "svn sync"
suggestion already goes in that direction.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Eric goes to lunch -- a decentralized-development user story
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Benjamin Pflugmann <be...@pflugmann.de>:
> Well, having had some days to let sink it in, I think the local-repo
> option has a more realistic chance to become implemented, as any
> change to libsvn_wc (and my suggestion would need those), will have a
> hard time to be accepted.
>
> > I'm listening and my mind is open, however.
>
> Well, since both our ideas would benefit from a specification of
> history diffs, we could take a step back and start with creating some
> fundament.
I went off and did some research. Among other things, I ran my eyeballs
over some dump files. I've learned that dump files don't normally contain diffs
at all -- when a node is changed in a revision, the revision contains
an entire copy of that node. (Of course the Subversion designers already
knew this.)
This isn't good for a history-diff format; simething like unified or
context diffs is better. The reason? Checking the context match can
help you spot clashes between what the diff expects and the actual state
of the code.
Accordingly, I'm reversing my previous contention. Dump files and history
diffs are *not* the same.
I'm now back to thinking that what we need is an action-diff format with
the following possible actions:
1. Apply diff
2. Add file
3. Delete file
4. Rename file
5. Set/clear property
and
6. Commit.
The "Commit" action would commit all diffs since the last commit action,
and could have a log message attached to it. Note: commits should be
timestamped and have a committer ID string (presumably a fully-qualified
developer@site.domain address) attached to them
--
<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: Eric goes to lunch -- a decentralized-development user story
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
On Thu 2004-09-16 at 22:52:07 -0400, Eric S. Raymond wrote:
> Benjamin Pflugmann <be...@pflugmann.de>:
> > Back to your premise: a dump file is a list of history diffs. A
> > repository is a dump file applied in order. But it's also more: it's a
> > filesystem with constraints (you cannot delete any of the history
> > diffs).
> >
> > So... not every storage of history diffs implies an order/sequence or
> > means you cannot delete those diffs anymore. (Although history diffs
> > started with an order in mind, you can easily exchange them as long as
> > the exchange doesn't create a conflict).
> >
> > So yes, patch management is some kind of repository, but it's not a
> > Subversion repository, except if you put some wrapper around it to
> > handle its constraints.
>
> Verry interresting. Yes, you've pointed out a real difference between a
> patch queue and a repo.
>
> I believe it is actually possible to zap revisions in a Subversion
> repo. There's a note about it in the Subversion book. It's
> discouraged, as I recall.
The possibility is to dump your repository, edit it (maybe by tools),
and create a new repository from it.
> Nevertheless, I think you have a point here. But it leads to the next
> question: would it be better to solve the problem local patch queues
> address with local patch queues, or by adding a policy option to repos
> that loosens the repudiability and ordering rules in an equivalent way,
> and using a local repo?
As I (tried to) say in my other email: either way is fine with me (not
that I matter much). I care more about the ease of the UI than the
implementation. I brought up implementation issues only because I
thought avoiding repos syncs maybe would be the easier way to get a
solution to the use cases.
> I like shaving with Occam's Razor. You know, "Do not multiply entities
> beyond necessity?" So I still have to lean towards the local-repo option.
Well, having had some days to let sink it in, I think the local-repo
option has a more realistic chance to become implemented, as any
change to libsvn_wc (and my suggestion would need those), will have a
hard time to be accepted.
> I'm listening and my mind is open, however.
Well, since both our ideas would benefit from a specification of
history diffs, we could take a step back and start with creating some
fundament.
Bye,
Benjamin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Eric goes to lunch -- a decentralized-development user story
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Benjamin Pflugmann <be...@pflugmann.de>:
> Back to your premise: a dump file is a list of history diffs. A
> repository is a dump file applied in order. But it's also more: it's a
> filesystem with constraints (you cannot delete any of the history
> diffs).
>
> So... not every storage of history diffs implies an order/sequence or
> means you cannot delete those diffs anymore. (Although history diffs
> started with an order in mind, you can easily exchange them as long as
> the exchange doesn't create a conflict).
>
> So yes, patch management is some kind of repository, but it's not a
> Subversion repository, except if you put some wrapper around it to
> handle its constraints.
Verry interresting. Yes, you've pointed out a real difference between a
patch queue and a repo.
I believe it is actually possible to zap revisions in a Subversion
repo. There's a note about it in the Subversion book. It's
discouraged, as I recall.
Nevertheless, I think you have a point here. But it leads to the next
question: would it be better to solve the problem local patch queues
address with local patch queues, or by adding a policy option to repos
that loosens the repudiability and ordering rules in an equivalent way,
and using a local repo?
I like shaving with Occam's Razor. You know, "Do not multiply entities
beyond necessity?" So I still have to lean towards the local-repo option.
I'm listening and my mind is open, however.
--
<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: Eric goes to lunch -- a decentralized-development user story
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
On Thu 2004-09-16 at 21:49:20 -0400, Eric S. Raymond wrote:
> Benjamin Pflugmann <be...@pflugmann.de>:
[...]
> > > For example, how do I save log text with my local patches?
> >
> > Okay, I always referred to action diffs, but I see no reason not to
> > store a history diff instead. I already implied that one should name
> > the checkpoint, there is no reason not to ask for log message, too.
>
> Right. I pointed at something that your iteration 0 notion of a local
> managed patch set didn't handle. You said (in effect) "no problem,
> we'll make the local patches history diffs rather than action diffs."
Yes and no. You are right, that are my words, but something different
happened than you seem to imply.
I already considered for my iteration 0 proposal whether I want
history diffs and decided that I wouldn't want a log message attached
(my patches go through too much iterations, so that I always write the
log message only when I commit).
> Remember the first premise, that a dump file is just a history diff
> on the empty tree? A repo is nothing but a sequence of history diffs.
> The moment that you say your local objects are history diffs, *you've
> just reinvented the repo*!
>
> *FLUSH* gurglegurglegurgle
>
> And that was the sound of "local patch management" going down the
> crapper.
Not really. I carry around with me the idea of how to improve patch
management in Subversion for a long time already. And one of the
implementation ideas I have gone through is to "simply" drive the
existing WC editors with the equivalent of what the server would send
for an update. So using action or history diffs is nothing new to
me... I just didn't have a name for them until this thread began.
I explained in my other email why I don't think this is the equivalent
of a local Subversion repository.
Back to your premise: a dump file is a list of history diffs. A
repository is a dump file applied in order. But it's also more: it's a
filesystem with constraints (you cannot delete any of the history
diffs).
So... not every storage of history diffs implies an order/sequence or
means you cannot delete those diffs anymore. (Although history diffs
started with an order in mind, you can easily exchange them as long as
the exchange doesn't create a conflict).
So yes, patch management is some kind of repository, but it's not a
Subversion repository, except if you put some wrapper around it to
handle its constraints.
It's getting late (4am) and I cannot express myself well anymore (if I
ever could), so I'll let this rest for now and see if I can explain it
better when I am up again.
Bye,
Benjamin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Eric goes to lunch -- a decentralized-development user story
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Benjamin Pflugmann <be...@pflugmann.de>:
> > I know immediately I'm going to run up against those limits.
>
> Really? How? Wanting to know more about that was what made me write my
> email to begin with. I don't mean to say you wouldn't run against
> those limits. It's just that I don't recall anybody, who asked for a
> local repository, present a use case in the Subversion context that
> wouldn't be solved by such a "patch management". (and I mean a real
> use case, something one already stumbled upon, not a theoretical one).
>
> > For example, how do I save log text with my local patches?
>
> Okay, I always referred to action diffs, but I see no reason not to
> store a history diff instead. I already implied that one should name
> the checkpoint, there is no reason not to ask for log message, too.
Right. I pointed at something that your iteration 0 notion of a local
managed patch set didn't handle. You said (in effect) "no problem,
we'll make the local patches history diffs rather than action diffs."
Remember the first premise, that a dump file is just a history diff
on the empty tree? A repo is nothing but a sequence of history diffs.
The moment that you say your local objects are history diffs, *you've
just reinvented the repo*!
*FLUSH* gurglegurglegurgle
And that was the sound of "local patch management" going down the crapper.
> Although I have no concrete reason against the idea of automatic
> branch creation in this context, the idea that after week-ends or
> similar events, the repository sees a lot of automatic branches which
> will live only for some minutes (until they are no longer needed),
> scares me a bit.
Reasonable. I'm not entirely happy with it myself and am trying to
come up with a better way.
--
<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: Eric goes to lunch -- a decentralized-development user story
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
On Thu 2004-09-16 at 19:33:35 -0400, Eric S. Raymond wrote:
> Benjamin Pflugmann <be...@pflugmann.de>:
> > As I see it, a solution to "2." would be some "patch management". If I
> > could checkpoint the WC, so that svn automatically saves an internal
> > (action) diff (under some given name), and then the working copy
> > behaves as if I checked in that change[1], creating several patches
> > would be a lot easier.
> >
> > In some way that would behave like a very limited local repository.
> > But in my case, such a limited feature would be probably enough. Of
> > course a plus would be, if there was some easy way to enable/disable
> > such checkpoints on the WC, without actually removing them.
> >
> > Then a checkin to an (updated) repository could become something like:
> > disable all checkpoints, svn up, re-enable checkpoint 1, resolve
> > conflicts if needed, commit, re-enable checkpoint 2, ... rinse and
> > repeat.
>
> It's an interesting idea, and in theory it might address the "Eric
> goes to lunch" case.
>
> The problem I have with it is that it proliferates mechanisms that are
> meant to accomplish the same thing rather than adding one clean new
> primitive notion.
Not really. There are things this approach handles better then a local
svn repository (e.g. easily disabling some of the patches again,
refactoring a patch after WC updating, and so on). Yes, those things
are also relatively easy done with a changeset oriented VC, but for
keeping my sources, I prefer the Subversion approach. It's just for
the work before commiting, I like a bit more flexibility than I have
today (with svk having a MS Windows port, I have to have a new look at
it).
> When you say "would behave like a very limited local repository"
> alarm bells go off in my head.
Well, that was only a side-comment to clarify my meaning.
> I know immediately I'm going to run up against those limits.
Really? How? Wanting to know more about that was what made me write my
email to begin with. I don't mean to say you wouldn't run against
those limits. It's just that I don't recall anybody, who asked for a
local repository, present a use case in the Subversion context that
wouldn't be solved by such a "patch management". (and I mean a real
use case, something one already stumbled upon, not a theoretical one).
> For example, how do I save log text with my local patches?
Okay, I always referred to action diffs, but I see no reason not to
store a history diff instead. I already implied that one should name
the checkpoint, there is no reason not to ask for log message, too.
But probably it would be more useful to handle the log message similar
to a property, so that it's easy editable.
But to be honest, I didn't plan out the idea to such a detail yet.
> How do I group them into change sets, if I'm working on more than
> one independent bug or feature?
I am not sure what you mean here. How would you group the changes if
if you had online access and would commit directly to the main
repository? Maybe if you give an example of that, I can understand
better (in other words: which other groups than commits are there?)
Or maybe you mean, how do you declare two patches to be one? Well, the
same way you would do now for a commit: apply both patches. And I
wouldn't expect the mechanism to be much different to the way you
would do with manual patch management: Either single out the one patch
you want to edit, apply it to the WC, edit, then save an updated
patch. Or do your changes, realize that it is an update to another
patch, apply the that patch over the changes you already made in the
WC and save the updated patch.
Okay, it gets a bit complex, once one wants to update older patches
and the update creates a conflict with newer patches. But that is a
conflict you would have to solve anyhow before commiting. So it's not
really a new class of problems.
> If it's going to walk like a local repo and quack like a local repo, I
> feel very strongly that it ought to *be* a local repo.
No, it wouldn't feel like a local repo. A repository preserves
history. These checkpoints wouldn't (if you change a change, you lost
your former change), because I would want to keep them simple. And it
would especially not feel like a Subversion repository. Rather, it
would similar to changeset oriented VCs, like darcs or monotone (no
comparison to bitkeeper, because I don't know it well enough).
But real changesets do much more than I need (btw, that's why I
explicitly avoided to mention changesets until now). And they are much
more complex to implement. That's why I call it support for patch
management. You can already do most of it by hand. It's just support
for doing it easier (and especially of the svn commands being aware of
'finished' changes, so that you can run "svn diff" and have it ignore
some of your already made patches).
[...]
> > I presented this idea, because I see some reasons against history
> > diffs:
> >
> > - Your example (rsync) needs a complete copy of the repository.
> > Although that can be reduced to syncing only the last revision with
> > some scripting (dump only HEAD, sync the dump file, load the local
> > repository with it), you have to know beforehand that you will work
> > offline and prepare.
>
> No, it's actually easier than that. You just treat the repo as a
> blob and rsync it. Only the changed bits have to come down the wire.
I was aware of that. But remember my words the first time you "just"
want to do an quick rsync of something like the emacs tree on your new
(and empty) notebook before heading to a train.
Your example needs a complete copy. Rsync only speeds it up as much as
your existing copy is recent. But yes, usually the speed-up will be
significant. But the unusual cases might hurt quite a bit.
Note that the process itself isn't quite as simple as it looks at
first glance, if you use the BDB-backend:
With BDB you have to:
1. Make sure no program accesses the local copy.
2. Pay attention to the sync order (logs last, see hotcopy tool for an
explanation).
3. Do a recover on the local copy in order to assure a consistent state.
4. (allow access again)
Reasonable scriptable, but not simple.
> > Such a feature is best, when you can simply continue where you left
> > off, when you still had repository access - without doing anything
> > special.
>
> I agree. I have some vague ideas about how to accomplish this
> involving introducing a new notion, that of a repo search path.
> But I'm not ready to write about that yet, it's not even half baked.
Ah, okay, if you see a solution on the horizon, then that point is moot.
> > - In case the main repository has received updates other than yours,
> > merging is needed and there is potential for conflicts. Although you
> > suggested some policies how to handle them, you cannot avoid a human
> > to be involved in conflict resolving sooner or later. Such resolving
> > currently happens in the working copy, so why not start the merge in
> > the WC to begin with? If there are no conflicts, patching and
> > commiting is a no-brainer, too.
>
> Reasonable point. My current thinking is that if a history diff does not
> apply clean, it creates a new branch. Then you get to svn merge to resolve
> the branch differences from trunk or whatever.
Hm. So you need to tell Subversion what your branching policy is.
Doesn't exist (currently Subversion has no clue which part of your
tree is considered a branch), but shouldn't be too hard to do.
Although I have no concrete reason against the idea of automatic
branch creation in this context, the idea that after week-ends or
similar events, the repository sees a lot of automatic branches which
will live only for some minutes (until they are no longer needed),
scares me a bit.
Sounds as much like a kluge to me like pseudo local repos. *eg*
But to come back to my original question: If you see a reason why a
more or less sophisticated patch management support wouldn't suffice
for you, I would love to hear it (more than any specific critic to the
details of implementation I just have come up with).
Bye,
Benjamin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Eric goes to lunch -- a decentralized-development user story
Posted by Dave Rolsky <au...@urth.org>.
On Thu, 16 Sep 2004, Eric S. Raymond wrote:
> Dave Rolsky <au...@urth.org>:
> > On Thu, 16 Sep 2004, Eric S. Raymond wrote:
> > > (This is part of the reason I'm dubious about svk. It appears to me
> > > to be guilty of the same sin.)
> >
> > Actually in SVK a local repo _is_ a local repo.
>
> Good! I'll go investigate svk more closely, then.
If you could write an emacs vc-mode for it while you're at it I'd be
pretty thrilled ;) The one thing that's keeping me from using SVK for
lots of things is the fact that the vc-mode keystrokes are embedded in my
working habits.
-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: Eric goes to lunch -- a decentralized-development user story
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Dave Rolsky <au...@urth.org>:
> On Thu, 16 Sep 2004, Eric S. Raymond wrote:
> > (This is part of the reason I'm dubious about svk. It appears to me
> > to be guilty of the same sin.)
>
> Actually in SVK a local repo _is_ a local repo.
Good! I'll go investigate svk more closely, then.
--
<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: Eric goes to lunch -- a decentralized-development user story
Posted by Dave Rolsky <au...@urth.org>.
On Thu, 16 Sep 2004, Eric S. Raymond wrote:
> If it's going to walk like a local repo and quack like a local repo, I
> feel very strongly that it ought to *be* a local repo. Otherwise
> we'll just be inviting headaches at the places where these overlapping
> mechanisms rub together.
>
> (This is part of the reason I'm dubious about svk. It appears to me
> to be guilty of the same sin.)
Actually in SVK a local repo _is_ a local repo. It _may_ (or may not)
have some metadata in it that points to another repo from which it can
sync. The syncing bits are provided by the SVN::Mirror and VCP Perl
modules, and are not in fact part of the core SVK code. The core SVK code
is a VC system based on subversion that uses local repositories and its
own working copy code.
But you could create a local repo and start checking stuff into it without
ever syncing against an existing repo first.
-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: Eric goes to lunch -- a decentralized-development user story
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Benjamin Pflugmann <be...@pflugmann.de>:
> As I see it, a solution to "2." would be some "patch management". If I
> could checkpoint the WC, so that svn automatically saves an internal
> (action) diff (under some given name), and then the working copy
> behaves as if I checked in that change[1], creating several patches
> would be a lot easier.
>
> In some way that would behave like a very limited local repository.
> But in my case, such a limited feature would be probably enough. Of
> course a plus would be, if there was some easy way to enable/disable
> such checkpoints on the WC, without actually removing them.
>
> Then a checkin to an (updated) repository could become something like:
> disable all checkpoints, svn up, re-enable checkpoint 1, resolve
> conflicts if needed, commit, re-enable checkpoint 2, ... rinse and
> repeat.
It's an interesting idea, and in theory it might address the "Eric
goes to lunch" case.
The problem I have with it is that it proliferates mechanisms that are
meant to accomplish the same thing rather than adding one clean new
primitive notion. When you say "would behave like a very limited
local repository" alarm bells go off in my head. I know immediately
I'm going to run up against those limits.
For example, how do I save log text with my local patches? How do I group
them into change sets, if I'm working on more than one independent
bug or feature?
If it's going to walk like a local repo and quack like a local repo, I
feel very strongly that it ought to *be* a local repo. Otherwise
we'll just be inviting headaches at the places where these overlapping
mechanisms rub together.
(This is part of the reason I'm dubious about svk. It appears to me
to be guilty of the same sin.)
> I presented this idea, because I see some reasons against history
> diffs:
>
> - Your example (rsync) needs a complete copy of the repository.
> Although that can be reduced to syncing only the last revision with
> some scripting (dump only HEAD, sync the dump file, load the local
> repository with it), you have to know beforehand that you will work
> offline and prepare.
No, it's actually easier than that. You just treat the repo as a
blob and rsync it. Only the changed bits have to come down the wire.
> Such a feature is best, when you can simply continue where you left
> off, when you still had repository access - without doing anything
> special.
I agree. I have some vague ideas about how to accomplish this
involving introducing a new notion, that of a repo search path.
But I'm not ready to write about that yet, it's not even half baked.
> - In case the main repository has received updates other than yours,
> merging is needed and there is potential for conflicts. Although you
> suggested some policies how to handle them, you cannot avoid a human
> to be involved in conflict resolving sooner or later. Such resolving
> currently happens in the working copy, so why not start the merge in
> the WC to begin with? If there are no conflicts, patching and
> commiting is a no-brainer, too.
Reasonable point. My current thinking is that if a history diff does not
apply clean, it creates a new branch. Then you get to svn merge to resolve
the branch differences from trunk or whatever.
--
<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: Eric goes to lunch -- a decentralized-development user story
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
On Thu 2004-09-16 at 19:35:36 -0400, Michael Sweet wrote:
> Benjamin Pflugmann wrote:
[...]
> I'm sure this would make the WC code that much more complex,
I am not sure about that. If you don't try to make it do too much
(i.e. a make-90%-happy approach), it should be mainly building on the
existing stuff (for example, there is already a method for applying a
delta on a WC; given a method for expressing the new revnum - as you
mentioned below - most of the code shouldn't need to care whether the
editor drive came from the server or a patch tool).
But maybe I am doing too much hand-waving here. And maybe such a
change is really only feasible in 2.0 after a WC lib rewrite.
> and expressing revnums might be a pain (do we adopt a revnum.savenum
> format for local saved changes or use revnum+N?),
Good point. I avoided that question 'til now, because I don't have an
idea.
> but it would provide considerable flexibility and support all of the
> use cases that have been expressed thus far...
Yes. Yes! :-)
If the use-cases are too demanding, we really end up with a local
changeset oriented repo (or microversioning as you called it). But
until now I didn't see anything to convince me that even a quite
simple implementation wouldn't solve the use cases of most people.
Bye,
Benjamin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Eric goes to lunch -- a decentralized-development user story
Posted by "C. Michael Pilato" <cm...@collab.net>.
Michael Sweet <mi...@easysw.com> writes:
> All of this sounds like providing a way to save WC versions (a la
> VMS file versions) might be enough to track/save local changes until
> they can be commited to the main repo. Whether you store fulltext
> copies in the .svn/text-base directory
> (.svn/text-base/filename.svn-base.1, filename.svn-base.2, etc.)
> or deltas/diffs would be an implementation detail, but my thought
> is that the WC would essentially become a mini-repo that can track
> micro-changes...
What's wrong? Subversion's WC code not slow enough for you yet? :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Eric goes to lunch -- a decentralized-development user story
Posted by Michael Sweet <mi...@easysw.com>.
Benjamin Pflugmann wrote:
> ...
> [1] E.g. "svn diff" would show only newer changes and so on. I am not
> sure of the details, but this would probably need to update the
> text-bases with the change. Since an action diff should be
> reversible (like a normal diff), there should be no problem to
> revert such a change and get back a WC to the prestine state.
All of this sounds like providing a way to save WC versions (a la
VMS file versions) might be enough to track/save local changes until
they can be commited to the main repo. Whether you store fulltext
copies in the .svn/text-base directory
(.svn/text-base/filename.svn-base.1, filename.svn-base.2, etc.)
or deltas/diffs would be an implementation detail, but my thought
is that the WC would essentially become a mini-repo that can track
micro-changes...
I'm sure this would make the WC code that much more complex, and
expressing revnums might be a pain (do we adopt a revnum.savenum
format for local saved changes or use revnum+N?), but it would
provide considerable flexibility and support all of the use cases
that have been expressed thus far...
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Printing Software for UNIX http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Eric goes to lunch -- a decentralized-development user story
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
On Thu 2004-09-16 at 16:34:46 -0400, Eric S. Raymond wrote:
[...]
> Yup. svk, your scripts, various kluges with rsync, Tom Lord's
> attempts to start a conversation way back when. I'm not under any
> illusion that I was first in with this.
What you described as your use case, can IMHO also be solved by "svn
supported patch management". So out of curiosity: Is there something
additional to your use case that needs history diffs, or would the
following solution also work for you?
Let me explain: I know a similar situation like you and cmpilato,
namely, when I want to write patches for a project where I don't have
write-access for the repository (like Subversion itself, the few times
I send in patches). Quite often I end up having several parallel,
independend changes in my WC.
My usual handling of such a situation is to create patches with svn
diff, save them, and reverse apply them to the WC, before I change to
the next change. This currently fails on two points:
1. svn diff loses some of the changes (properties, move, and so on).
2. it's quite a pain to manually handle large amount of patches.
Point 1 will be solved when action diffs are introduced. So if there
was a solution for 2., most of my needs would be solved. As I
understand, it would also solve cmpilato's use case, and yours. Am I
correct?
As I see it, a solution to "2." would be some "patch management". If I
could checkpoint the WC, so that svn automatically saves an internal
(action) diff (under some given name), and then the working copy
behaves as if I checked in that change[1], creating several patches
would be a lot easier.
In some way that would behave like a very limited local repository.
But in my case, such a limited feature would be probably enough. Of
course a plus would be, if there was some easy way to enable/disable
such checkpoints on the WC, without actually removing them.
Then a checkin to an (updated) repository could become something like:
disable all checkpoints, svn up, re-enable checkpoint 1, resolve
conflicts if needed, commit, re-enable checkpoint 2, ... rinse and
repeat.
There is also a problem with my checkpoint suggestion: It needs
changes to the WC lib and most people agree not the implement new
features to that before a rewrite happened. On the other hand, my
suggestion reuses a lot of what is already in the lib.
I presented this idea, because I see some reasons against history
diffs:
- Your example (rsync) needs a complete copy of the repository.
Although that can be reduced to syncing only the last revision with
some scripting (dump only HEAD, sync the dump file, load the local
repository with it), you have to know beforehand that you will work
offline and prepare.
Such a feature is best, when you can simply continue where you left
off, when you still had repository access - without doing anything
special. (If I understood correctly, cmpilato's procedure works this
way, because he produces the local repository by checking in his
WC... which sounds quite hackish to me ;)
- In case the main repository has received updates other than yours,
merging is needed and there is potential for conflicts. Although you
suggested some policies how to handle them, you cannot avoid a human
to be involved in conflict resolving sooner or later. Such resolving
currently happens in the working copy, so why not start the merge in
the WC to begin with? If there are no conflicts, patching and
commiting is a no-brainer, too.
Well, hope that idea wasn't obvious to everybody already.
Bye,
Benjamin.
[1] E.g. "svn diff" would show only newer changes and so on. I am not
sure of the details, but this would probably need to update the
text-bases with the change. Since an action diff should be
reversible (like a normal diff), there should be no problem to
revert such a change and get back a WC to the prestine state.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Eric goes to lunch -- a decentralized-development user story
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
C. Michael Pilato <cm...@collab.net>:
> No, that's not true. I sequentially apply each revision from my
> temporary repository to my "real" work copy, and can commit up each of
> this changes individually, even pulling the original log message for
> that change from the temporary repository.
Correction accepted.
> Now, I'll grant you that because I've not taken the time to script
> this process, it's almost more headache than it's worth. But please
> don't imagine that the case for some VC decentralization was first
> made by Eric Raymond on today's Subversion list. :-) It's happening
> already, in various forms, and with various degrees of ease/pain.
Yup. svk, your scripts, various kluges with rsync, Tom Lord's
attempts to start a conversation way back when. I'm not under any
illusion that I was first in with this.
> So, I agree. There *is* utility in some decentralization. The catch
> is harvesting that utility while throttling the chaos that can quite
> easily ensue.
Also agreed. And this is exactly where I think I can be useful. I've
been thinking about these issues for a long time, I'm not so up to my
ears in the details of svn's implementation ythat it's hard for me to
think in other terms, and I have some design sense.
I think we've already made some significant progress in this discussion.
1. We understand what the relationship between action diffs, history diffs,
and dumpfiles has to be. That doesn't solve the policy questions, but
it does outline the shape of the mechanism.
2. We have an svk advocate in the conversation.
3. We've got two good use cases on the table ("Eric goes to lunch" and
Philip's AS/4000 scenario) to which people are reacting in
informative ways.
These are all good. We're nowhere near the point of coding yet, but we're
making headway on some important design issues.
--
<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: Eric goes to lunch -- a decentralized-development user story
Posted by "C. Michael Pilato" <cm...@collab.net>.
"Eric S. Raymond" <es...@thyrsus.com> writes:
> Yeah, OK. But you're forced to treat all the work you do offline as
> one big lump expressed by one big patch, and you don't get the log
> messages on your local commits automatically propagated up to the main
> repo along with the patch.
No, that's not true. I sequentially apply each revision from my
temporary repository to my "real" work copy, and can commit up each of
this changes individually, even pulling the original log message for
that change from the temporary repository.
Now, I'll grant you that because I've not taken the time to script
this process, it's almost more headache than it's worth. But please
don't imagine that the case for some VC decentralization was first
made by Eric Raymond on today's Subversion list. :-) It's happening
already, in various forms, and with various degrees of ease/pain.
So, I agree. There *is* utility in some decentralization. The catch
is harvesting that utility while throttling the chaos that can quite
easily ensue.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Eric goes to lunch -- a decentralized-development user story
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
C. Michael Pilato <cm...@collab.net>:
> I do this kind of thing all the time, since two hours of my daily life
> are spent on trains. Committing to a temporary repos (just an import
> of my working copy state as of the time I left the office) and then
> replaying commits later into my real working copy using 'patch | svn
> diff -rX:Y', I can do almost everything I need to do. Only place this
> really hurts me is if copies and moves are needed -- but they only
> very rarely are.
Yeah, OK. But you're forced to treat all the work you do offline as
one big lump expressed by one big patch, and you don't get the log
messages on your local commits automatically propagated up to the main
repo along with the patch.
These, to me, are bigger issues than copies or moves. I agree that
those are rare.
--
<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: Eric goes to lunch -- a decentralized-development user story
Posted by "C. Michael Pilato" <cm...@collab.net>.
"Eric S. Raymond" <es...@snark.thyrsus.com> writes:
> Now things are better. Before bicycling to lunch, Eric ran a one-line
> shellscript that uses rsync to update a local copy of the gpsd
> repository on his laptop:
>
> rsync http://svn.berlios.de/svnroot/gpsd ~/svn/gpsd/SVN
>
> As he eats lunch, he does commits to that local repository. When he
> gets within range of his wireless net again, he runs another one-line
> shellscript from within his working-copy directory that does this:
>
> svn sync http://svn.berlios.de/svnroot/gpsd
I do this kind of thing all the time, since two hours of my daily life
are spent on trains. Committing to a temporary repos (just an import
of my working copy state as of the time I left the office) and then
replaying commits later into my real working copy using 'patch | svn
diff -rX:Y', I can do almost everything I need to do. Only place this
really hurts me is if copies and moves are needed -- but they only
very rarely are.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Eric goes to lunch -- a decentralized-development user story
Posted by John Peacock <jp...@rowman.com>.
Joerg Hessdoerfer wrote:
> We can't use svk - we're a shop heavily using Windows (and I understand it
> doesn't work on windows, right?).
It does now:
http://svk.elixus.org/index.cgi?SVKWin32
HTH
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: Eric goes to lunch -- a decentralized-development user story
Posted by Joerg Hessdoerfer <Jo...@sea-gmbh.com>.
Hi,
I've just decided to look into this, as this is what we need also - we often
do work 'on the road' at customer's location without write access to our
repo. I wrote a simple shell script (see attachment) using dump/load for this
purpose. I called the 'fixed' repository 'central' and the 'on the road one'
'local'. It seems to work fine, except:
1) modifications to files in the central repository get lost after load of
local repository
2) the svnadmin dump only works locally (ok, one could use CGI or ssh or...)
This seems to solve the 'Eric' story, but it's not what we need. We would need
the central mods to be kept, too. Would introducing branch/merge help here?
We can't use svk - we're a shop heavily using Windows (and I understand it
doesn't work on windows, right?).
Greetings,
Joerg
--
Leading SW developer - S.E.A GmbH
Mail: joerg.hessdoerfer@sea-gmbh.com
WWW: http://www.sea-gmbh.com