Discussion:
[p4] Working disconnected - on steroids
Carsten Orthbandt
2004-01-18 00:01:26 UTC
Permalink
Here's something I've been trying to solve for months now...

In office, I use our company perforce server for nearly everything.
But for private projects and at home, I use a p4s running locally
on my notebook. Now while there's nothing interesting on that notebook
that isn't automatically mirrored with our company infrastructure
(everything in MS Outlook hooked to an Exchange Server), I don't see
an easy way to do the same with my local P4 depots.
My notebook acts as a client to both p4 servers.
The easy way would be to apply the known "working disconnected"
techniques in a two-way fashion.
But: Of course I want all my changes on both depots to stay.
And I want full history. So when I sit at home and do 10 revisions
of a file, I'd like to mirror these 10 revisions into the company
server when I'm back at the office. And vice versa.

The task as I see it is actually a two-level challenge:
1st: Master the "private projects" part. This won't involve any
conflicts since I'd be the only one doing changes to a
project at any point in time. And I'd be doing these changes
on only one machine and get to sync the two before switching
workplaces.
2nd: Doing it reliably with multi-user projects. As far as I can
see, this involves merging multiple parallel changes. And as
I understand it, this might prove quite hard.

Example:

Private machine A Company machine B
file#10 file#10 - in sync
- leaving the office now
file#11b - some coworker doing changes
file#12b - some coworker doing more changes
file#11a - me doing changes at home
file#12a - and more
file#13a - I'm really in the mood
- coming back to the office

So what to do now?

Solution 1 I came up with is this:
- submit #11a-#12a to Company machine as #13b-#14b, ignoring the fact
that they aren't actually succeeding #12b, but #10
- submit #11b and #12b to A, creating #14a and #15a
- merge the two changes #10-13a and #10-12b, submit as #16a to A
and #15b _AND_ #16b to B, so I have the same rev numbers again

Actually, that's the wrong way around, since I'd have to do the last
submit to the company server first, to allow for further merging
if someone else did a #13b while I was trying to catch up.

Solution 2 is this:
- submit all A changes to B to get to same file history
- open a branch on B, client at A
- work disconnected
- come back
- iteratively submit all mobile changes to the branch on B
- merge branch with B main line
- "fake" revs on B unseen by A into B's history by submitting
them afterwards
- submit merged branch to A
- do dummy submit on one of the two to sync-up rev numbers if needed

This seems to be the cleaner way, but I think it would leave traces
in form of no-change branches everytime I leave if I don't do anything
at home. Plus AFAIK, I can't do branches on file I don't have in my
client view. So I'd either have to keep two copies on my notebook or
change the notebook's client spec automatically.

Solution 3 is the same as 2, but I could open the branch on A only
when I come back to the office and only if I actually changed
something.

I have no problem with one of the two P4 sites being the "master",
but somehow I hope there's some better solution. Any better ideas?

Bonus points for methods that don't have to lie on the timestamps
and change order. Bat as far as I can see, this would involve heavy
checkpoint surgery and scary changes to the RSC files.

Somehow I have the gut feeling of missing a mire obvious and elegant
solution to this...

Best regards,

Carsten Orthbandt
Founder + Development Director
SEK SpieleEntwicklungsKombinat GmbH
http://www.sek-ost.de

Wenn ich Visionen habe, gehe ich zum Arzt. - Helmut Schmidt
s***@vance.com
2004-01-18 00:52:39 UTC
Permalink
Just a couple of thoughts.

What you're really looking for is implemented in some of the open source
systems (and a couple commercial ones) as distributed repositories. Rather
than branching, you actually clone the repository in a way that it can be
reconciled back like a branch.

You can accomplish something like this with integrating back and forth
between remote depots. It doesn't preserve change list numbering and unless
you integrate changes one-by-one, you'll generally get rollups of the
changes similar to how you would with the working disconnected strategy.

The scalability of this solution depends heavily on your branching
complexity. The most scalably way to do it is with a hub-and-spoke model,
but even that could get difficult with dozens of users in a way that it
wouldn't with a handful of sites.

A tool that I like a few years ago was the P4 Emulator. Basically it was a
Perl script that simulated edit, delete, add and revert for one change list
with a local database and could replay it into the real server when you
reconnected. With extensions it could probably work for multiple change
lists and integrates as long as source and destination were present.

You can also look at perfmerge2.pl as a means of reconciling two different
depots of development, although it would be quite impractical to do frequent
merges for multiple users.

Finally, you should look at whether vcp can do the trick for you. It is
designed for transporting metadata between instances and disparate systems
and I understand it has the ability to do incremental transfers.

Steve
Post by Carsten Orthbandt
Here's something I've been trying to solve for months now...
In office, I use our company perforce server for nearly everything.
But for private projects and at home, I use a p4s running locally
on my notebook. Now while there's nothing interesting on that notebook
that isn't automatically mirrored with our company infrastructure
(everything in MS Outlook hooked to an Exchange Server), I don't see
an easy way to do the same with my local P4 depots.
My notebook acts as a client to both p4 servers.
The easy way would be to apply the known "working disconnected"
techniques in a two-way fashion.
But: Of course I want all my changes on both depots to stay.
And I want full history. So when I sit at home and do 10 revisions
of a file, I'd like to mirror these 10 revisions into the company
server when I'm back at the office. And vice versa.
1st: Master the "private projects" part. This won't involve any
conflicts since I'd be the only one doing changes to a
project at any point in time. And I'd be doing these changes
on only one machine and get to sync the two before switching
workplaces.
2nd: Doing it reliably with multi-user projects. As far as I can
see, this involves merging multiple parallel changes. And as
I understand it, this might prove quite hard.
Private machine A Company machine B
file#10 file#10 - in sync
- leaving the office now
file#11b - some coworker doing changes
file#12b - some coworker doing more changes
file#11a - me doing changes at home
file#12a - and more
file#13a - I'm really in the mood
- coming back to the office
So what to do now?
- submit #11a-#12a to Company machine as #13b-#14b, ignoring the fact
that they aren't actually succeeding #12b, but #10
- submit #11b and #12b to A, creating #14a and #15a
- merge the two changes #10-13a and #10-12b, submit as #16a to A
and #15b _AND_ #16b to B, so I have the same rev numbers again
Actually, that's the wrong way around, since I'd have to do the last
submit to the company server first, to allow for further merging
if someone else did a #13b while I was trying to catch up.
- submit all A changes to B to get to same file history
- open a branch on B, client at A
- work disconnected
- come back
- iteratively submit all mobile changes to the branch on B
- merge branch with B main line
- "fake" revs on B unseen by A into B's history by submitting
them afterwards
- submit merged branch to A
- do dummy submit on one of the two to sync-up rev numbers if needed
This seems to be the cleaner way, but I think it would leave traces
in form of no-change branches everytime I leave if I don't do anything
at home. Plus AFAIK, I can't do branches on file I don't have in my
client view. So I'd either have to keep two copies on my notebook or
change the notebook's client spec automatically.
Solution 3 is the same as 2, but I could open the branch on A only
when I come back to the office and only if I actually changed
something.
I have no problem with one of the two P4 sites being the "master",
but somehow I hope there's some better solution. Any better ideas?
Bonus points for methods that don't have to lie on the timestamps
and change order. Bat as far as I can see, this would involve heavy
checkpoint surgery and scary changes to the RSC files.
Somehow I have the gut feeling of missing a mire obvious and elegant
solution to this...
Best regards,
Carsten Orthbandt
Founder + Development Director
SEK SpieleEntwicklungsKombinat GmbH
http://www.sek-ost.de
Wenn ich Visionen habe, gehe ich zum Arzt. - Helmut Schmidt
_______________________________________________
http://maillist.perforce.com/mailman/listinfo/perforce-user
====================
Stephen Vance
http://www.vance.com
Chuck Karish
2004-01-18 14:34:30 UTC
Permalink
Solution 4: Use VCP to keep the two repositories in sync.
- Make a separate client workspace for each server.
- Sync from B to A before you leave the office, with VCP.
- Sync and merge from B to A when you return to the office, with VCP.
- Sync and merge A-only changes (not the resolves) from A to B, with VCP.
- Diff the files to be sure your resolves have the same result on both
sides.

Good news: You won't have to lie to Perforce at all.
Bad news: You'll have to sync the full change stream from B
to A through VCP.
You'll have to do resolves on both repositories.
The change histories will be different.

Chuck
Post by Carsten Orthbandt
Private machine A Company machine B
file#10 file#10 - in sync
- leaving the office now
file#11b - some coworker doing changes
file#12b - some coworker doing more changes
file#11a - me doing changes at home
file#12a - and more
file#13a - I'm really in the mood
- coming back to the office
So what to do now?
- submit #11a-#12a to Company machine as #13b-#14b, ignoring the fact
that they aren't actually succeeding #12b, but #10
- submit #11b and #12b to A, creating #14a and #15a
- merge the two changes #10-13a and #10-12b, submit as #16a to A
and #15b _AND_ #16b to B, so I have the same rev numbers again
Actually, that's the wrong way around, since I'd have to do the last
submit to the company server first, to allow for further merging
if someone else did a #13b while I was trying to catch up.
- submit all A changes to B to get to same file history
- open a branch on B, client at A
- work disconnected
- come back
- iteratively submit all mobile changes to the branch on B
- merge branch with B main line
- "fake" revs on B unseen by A into B's history by submitting
them afterwards
- submit merged branch to A
- do dummy submit on one of the two to sync-up rev numbers if needed
This seems to be the cleaner way, but I think it would leave traces
in form of no-change branches everytime I leave if I don't do anything
at home. Plus AFAIK, I can't do branches on file I don't have in my
client view. So I'd either have to keep two copies on my notebook or
change the notebook's client spec automatically.
Solution 3 is the same as 2, but I could open the branch on A only
when I come back to the office and only if I actually changed
something.
Gregg G. Wonderly
2004-01-18 14:34:31 UTC
Permalink
Post by Carsten Orthbandt
Here's something I've been trying to solve for months now...
In office, I use our company perforce server for nearly everything.
But for private projects and at home, I use a p4s running locally
on my notebook. Now while there's nothing interesting on that notebook
that isn't automatically mirrored with our company infrastructure
(everything in MS Outlook hooked to an Exchange Server), I don't see
an easy way to do the same with my local P4 depots.
My notebook acts as a client to both p4 servers.
When I am working disconnected, I just change the files to read/write and have
at it. I use 'p4 diff -se ... | p4 -x - edit' when I reconnect. I generally
do not have a need to make more than a single delta on a particular file.
Now, my IDE supports doing checkout vs read/write itself so I don't have to go
do the change to writeable litteraly. Also, my simple text editor (Lemmy, a
vi clone for windows) lets me force an overwrite on read-only. The important
thing is to remember to do the 'p4 diff -se ...'. But this has not been a
problematic way of operating for me.

I also hook my laptop up to my cell phone, in a pinch, connect to the VPN and
do anything I absolutely must do against the server. It's slow for big files,
so generally I only use this sparingly.

-----
***@cytetech.com (Cyte Technologies Inc)
Rob Jellinghaus
2004-01-21 19:12:22 UTC
Permalink
Really Perforce is the wrong tool for this job. Something like
Bitkeeper or OpenCM -- both of which have truly distributed repository
designs, with support for merging whole change histories across
repositories -- are what you want.

Perforce has many strengths, but genuinely distributed development is
not one of them.

Cheers!
Rob

-----Original Message-----
From: perforce-user-***@perforce.com
[mailto:perforce-user-***@perforce.com] On Behalf Of Chuck Karish
Sent: Sunday, January 18, 2004 6:35 AM
To: Carsten Orthbandt
Cc: perforce-***@perforce.com
Subject: Re: [p4] Working disconnected - on steroids

Solution 4: Use VCP to keep the two repositories in sync.
- Make a separate client workspace for each server.
- Sync from B to A before you leave the office, with VCP.
- Sync and merge from B to A when you return to the office, with VCP.
- Sync and merge A-only changes (not the resolves) from A to B, with
VCP.
- Diff the files to be sure your resolves have the same result on both
sides.

Good news: You won't have to lie to Perforce at all.
Bad news: You'll have to sync the full change stream from B
to A through VCP.
You'll have to do resolves on both repositories.
The change histories will be different.

Chuck
Post by Carsten Orthbandt
Private machine A Company machine B
file#10 file#10 - in sync
- leaving the office now
file#11b - some coworker doing changes
file#12b - some coworker doing more changes
file#11a - me doing changes at home
file#12a - and more
file#13a - I'm really in the mood
- coming back to the office
So what to do now?
- submit #11a-#12a to Company machine as #13b-#14b, ignoring the fact
that they aren't actually succeeding #12b, but #10
- submit #11b and #12b to A, creating #14a and #15a
- merge the two changes #10-13a and #10-12b, submit as #16a to A
and #15b _AND_ #16b to B, so I have the same rev numbers again
Actually, that's the wrong way around, since I'd have to do the last
submit to the company server first, to allow for further merging
if someone else did a #13b while I was trying to catch up.
- submit all A changes to B to get to same file history
- open a branch on B, client at A
- work disconnected
- come back
- iteratively submit all mobile changes to the branch on B
- merge branch with B main line
- "fake" revs on B unseen by A into B's history by submitting
them afterwards
- submit merged branch to A
- do dummy submit on one of the two to sync-up rev numbers if needed
This seems to be the cleaner way, but I think it would leave traces
in form of no-change branches everytime I leave if I don't do anything
at home. Plus AFAIK, I can't do branches on file I don't have in my
client view. So I'd either have to keep two copies on my notebook or
change the notebook's client spec automatically.
Solution 3 is the same as 2, but I could open the branch on A only
when I come back to the office and only if I actually changed
something.
_______________________________________________
perforce-user mailing list - perforce-***@perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user

Continue reading on narkive:
Loading...