wc-ng and a reference wc

[Bob Jenkins <rj...@collab.net>]

I have heard some of some potential limitations in the ability to move
or copy the new working copy which concern me so I want to see if the
following use case is going to be supported. I know of several
organizations where the checkout operation is particularly painful. In
order to deal with that, they've established (many times with my
recommendation) a "reference" working copy which is kept up-to-date and
which individual users copy to create their own working copy. I fully
appreciated that they would not be able to copy only a sub-tree of a
working copy moving forward, but I've heard that maybe a working copy
cannot be moved and therefore copied to another machine. Is that the
case? If so, then this is a significant issue which will only further
exasperate the distributed development situation. Assuming it is the
case, I'm not sure why this would have to be a limitation (recognizing
I'm not a coder so I see things only from the surface) so enlighten me
if he does have to be a limitation.

 

Thanks,

 

Bob Jenkins

Re: wc-ng and a reference wc

[Greg Stein <gs...@gmail.com>]

On Thu, Mar 4, 2010 at 19:43, Neels J Hofmeyr <ne...@elego.de> wrote:
> Neels J Hofmeyr wrote:
>> Just a thought: the 'svn up' will copy all those pristines to the user area.
>> If it's faster to copy from the other device than within the same device
>> (where the working copy is), copying everything can be faster.

It really depends. If the source is on a network drive (which I
assumed because it was for a whole development team), then a copy of
the metadata+pristines followed by a local-restore could be faster.

But it was mostly just a thought. I certainly don't recommend making
use of such "internal" knowledge of the capabilities of the .svn
subdir.

> Plus, the 'svn up' will, probably, *validate the checksums* of all pristines
> while restoring the working copy. That would slow the whole thing down
> substantially. Hmmm...

I really doubt it. My belief is the process will be I/O-bound, so the
extra CPU spent computing checksums will not be a big issue (unless
you have an SSD or some other fast local drive, of course). That was
part of our earlier discussion: assuming an I/O-bound process, rather
than CPU-bound. But given that certain scenarios could end up
CPU-bound, this is why we'd like to optimize-away the checksums
(rather than leaving them always-on, per default).

Cheers,
-g

Re: wc-ng and a reference wc

[Neels J Hofmeyr <ne...@elego.de>]

Neels J Hofmeyr wrote:
> Just a thought: the 'svn up' will copy all those pristines to the user area.
> If it's faster to copy from the other device than within the same device
> (where the working copy is), copying everything can be faster.

Plus, the 'svn up' will, probably, *validate the checksums* of all pristines
while restoring the working copy. That would slow the whole thing down
substantially. Hmmm...

* neels makes a mental note of the 'copy-to-user-area' use cases
  for the pristine store design.

~Neels

> 
> Bob Jenkins wrote:
>> Thanks Greg and Philip! Your secret's safe with me :-)
>>
>> Bob
>>
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein@gmail.com] 
>> Sent: Tuesday, March 02, 2010 4:36 PM
>> To: Bob Jenkins; Philip Martin
>> Cc: dev@subversion.apache.org
>> Subject: Re: wc-ng and a reference wc
>>
>> On Tue, Mar 2, 2010 at 11:36, Philip Martin <ph...@wandisco.com> wrote:
>>> "Bob Jenkins" <rj...@collab.net> writes:
>>>
>>>> they've established (many times with my
>>>> recommendation) a "reference" working copy which is kept up-to-date and
>>>> which individual users copy to create their own working copy. I fully
>>>> appreciated that they would not be able to copy only a sub-tree of a
>>>> working copy moving forward, but I've heard that maybe a working copy
>>>> cannot be moved and therefore copied to another machine. Is that the
>>>> case?
>>> 1.7 is going to support centralised metadata in the root of the
>>> working copy and copying that sort of working copy will continue to
>>> work.  1.7 might also support metadata outside the working copy, if it
>>> does it would be optional and copying that sort of working copy would
>>> be more complicated.  In either case I expect that copying a subtree
>>> will also be possible, either via some sort of svn-detach script, or
>>> perhaps an 'svn detach' command.
>> To amend: I'm not sure that anybody has set aside time in the 1.7
>> release for doing outside-metadata nor a detach command.
>>
>> Bob: your client should be able to copy the *entire* working copy,
>> from the root (where the metadata is) on downwards. But they will not
>> be able to copy subtrees. You would need to set up separate copy
>> sources for subtrees of interest.
>>
>> It will also be possible to do a "shallow copy", as long as you get
>> that root directory and its metadata. Hmm. In fact, that might be the
>> fastest thing to do for your users:
>>
>> $ mkdir my-working-copy
>> $ cp -r $SOURCE_TREE/.svn my-working-copy/.svn
>> $ cd my-working-copy
>> $ svn up
>>
>> Subversion should then "restore" every file and directory in the
>> working copy from the pristines located in .svn (note that the cp will
>> take a bit, since it is copying all the pristines; but the neat thing
>> is taking advantage of svn's restoring feature, and that we can do it
>> for dirs now, too).
>>
>> Okay. Now don't tell anybody I told you this "monkey with .svn" secret.
>>
>> :-)
>>
>> Cheers,
>> -g
> 

Re: wc-ng and a reference wc

[Neels J Hofmeyr <ne...@elego.de>]

Just a thought: the 'svn up' will copy all those pristines to the user area.
If it's faster to copy from the other device than within the same device
(where the working copy is), copying everything can be faster.

~Neels

Bob Jenkins wrote:
> Thanks Greg and Philip! Your secret's safe with me :-)
> 
> Bob
> 
> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com] 
> Sent: Tuesday, March 02, 2010 4:36 PM
> To: Bob Jenkins; Philip Martin
> Cc: dev@subversion.apache.org
> Subject: Re: wc-ng and a reference wc
> 
> On Tue, Mar 2, 2010 at 11:36, Philip Martin <ph...@wandisco.com> wrote:
>> "Bob Jenkins" <rj...@collab.net> writes:
>>
>>> they've established (many times with my
>>> recommendation) a "reference" working copy which is kept up-to-date and
>>> which individual users copy to create their own working copy. I fully
>>> appreciated that they would not be able to copy only a sub-tree of a
>>> working copy moving forward, but I've heard that maybe a working copy
>>> cannot be moved and therefore copied to another machine. Is that the
>>> case?
>> 1.7 is going to support centralised metadata in the root of the
>> working copy and copying that sort of working copy will continue to
>> work.  1.7 might also support metadata outside the working copy, if it
>> does it would be optional and copying that sort of working copy would
>> be more complicated.  In either case I expect that copying a subtree
>> will also be possible, either via some sort of svn-detach script, or
>> perhaps an 'svn detach' command.
> 
> To amend: I'm not sure that anybody has set aside time in the 1.7
> release for doing outside-metadata nor a detach command.
> 
> Bob: your client should be able to copy the *entire* working copy,
> from the root (where the metadata is) on downwards. But they will not
> be able to copy subtrees. You would need to set up separate copy
> sources for subtrees of interest.
> 
> It will also be possible to do a "shallow copy", as long as you get
> that root directory and its metadata. Hmm. In fact, that might be the
> fastest thing to do for your users:
> 
> $ mkdir my-working-copy
> $ cp -r $SOURCE_TREE/.svn my-working-copy/.svn
> $ cd my-working-copy
> $ svn up
> 
> Subversion should then "restore" every file and directory in the
> working copy from the pristines located in .svn (note that the cp will
> take a bit, since it is copying all the pristines; but the neat thing
> is taking advantage of svn's restoring feature, and that we can do it
> for dirs now, too).
> 
> Okay. Now don't tell anybody I told you this "monkey with .svn" secret.
> 
> :-)
> 
> Cheers,
> -g

RE: wc-ng and a reference wc

[Bob Jenkins <rj...@collab.net>]

Thanks Greg and Philip! Your secret's safe with me :-)

Bob

-----Original Message-----
From: Greg Stein [mailto:gstein@gmail.com] 
Sent: Tuesday, March 02, 2010 4:36 PM
To: Bob Jenkins; Philip Martin
Cc: dev@subversion.apache.org
Subject: Re: wc-ng and a reference wc

On Tue, Mar 2, 2010 at 11:36, Philip Martin <ph...@wandisco.com> wrote:
> "Bob Jenkins" <rj...@collab.net> writes:
>
>> they've established (many times with my
>> recommendation) a "reference" working copy which is kept up-to-date and
>> which individual users copy to create their own working copy. I fully
>> appreciated that they would not be able to copy only a sub-tree of a
>> working copy moving forward, but I've heard that maybe a working copy
>> cannot be moved and therefore copied to another machine. Is that the
>> case?
>
> 1.7 is going to support centralised metadata in the root of the
> working copy and copying that sort of working copy will continue to
> work.  1.7 might also support metadata outside the working copy, if it
> does it would be optional and copying that sort of working copy would
> be more complicated.  In either case I expect that copying a subtree
> will also be possible, either via some sort of svn-detach script, or
> perhaps an 'svn detach' command.

To amend: I'm not sure that anybody has set aside time in the 1.7
release for doing outside-metadata nor a detach command.

Bob: your client should be able to copy the *entire* working copy,
from the root (where the metadata is) on downwards. But they will not
be able to copy subtrees. You would need to set up separate copy
sources for subtrees of interest.

It will also be possible to do a "shallow copy", as long as you get
that root directory and its metadata. Hmm. In fact, that might be the
fastest thing to do for your users:

$ mkdir my-working-copy
$ cp -r $SOURCE_TREE/.svn my-working-copy/.svn
$ cd my-working-copy
$ svn up

Subversion should then "restore" every file and directory in the
working copy from the pristines located in .svn (note that the cp will
take a bit, since it is copying all the pristines; but the neat thing
is taking advantage of svn's restoring feature, and that we can do it
for dirs now, too).

Okay. Now don't tell anybody I told you this "monkey with .svn" secret.

:-)

Cheers,
-g

Re: wc-ng and a reference wc

[Greg Stein <gs...@gmail.com>]

On Tue, Mar 2, 2010 at 11:36, Philip Martin <ph...@wandisco.com> wrote:
> "Bob Jenkins" <rj...@collab.net> writes:
>
>> they've established (many times with my
>> recommendation) a "reference" working copy which is kept up-to-date and
>> which individual users copy to create their own working copy. I fully
>> appreciated that they would not be able to copy only a sub-tree of a
>> working copy moving forward, but I've heard that maybe a working copy
>> cannot be moved and therefore copied to another machine. Is that the
>> case?
>
> 1.7 is going to support centralised metadata in the root of the
> working copy and copying that sort of working copy will continue to
> work.  1.7 might also support metadata outside the working copy, if it
> does it would be optional and copying that sort of working copy would
> be more complicated.  In either case I expect that copying a subtree
> will also be possible, either via some sort of svn-detach script, or
> perhaps an 'svn detach' command.

To amend: I'm not sure that anybody has set aside time in the 1.7
release for doing outside-metadata nor a detach command.

Bob: your client should be able to copy the *entire* working copy,
from the root (where the metadata is) on downwards. But they will not
be able to copy subtrees. You would need to set up separate copy
sources for subtrees of interest.

It will also be possible to do a "shallow copy", as long as you get
that root directory and its metadata. Hmm. In fact, that might be the
fastest thing to do for your users:

$ mkdir my-working-copy
$ cp -r $SOURCE_TREE/.svn my-working-copy/.svn
$ cd my-working-copy
$ svn up

Subversion should then "restore" every file and directory in the
working copy from the pristines located in .svn (note that the cp will
take a bit, since it is copying all the pristines; but the neat thing
is taking advantage of svn's restoring feature, and that we can do it
for dirs now, too).

Okay. Now don't tell anybody I told you this "monkey with .svn" secret.

:-)

Cheers,
-g

Re: wc-ng and a reference wc

[Philip Martin <ph...@wandisco.com>]

"Bob Jenkins" <rj...@collab.net> writes:

> they've established (many times with my
> recommendation) a "reference" working copy which is kept up-to-date and
> which individual users copy to create their own working copy. I fully
> appreciated that they would not be able to copy only a sub-tree of a
> working copy moving forward, but I've heard that maybe a working copy
> cannot be moved and therefore copied to another machine. Is that the
> case?

1.7 is going to support centralised metadata in the root of the
working copy and copying that sort of working copy will continue to
work.  1.7 might also support metadata outside the working copy, if it
does it would be optional and copying that sort of working copy would
be more complicated.  In either case I expect that copying a subtree
will also be possible, either via some sort of svn-detach script, or
perhaps an 'svn detach' command.

-- 
Philip