You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@gmail.com> on 2008/09/15 00:23:34 UTC
Base text files, re: IRC chat
Erik,
On IRC, you wrote:
[1:49pm] ehu: gstein_: here? some more remarks regarding wc-ng.
[1:50pm] ehu: gstein_: in wc-1.0, we gave the base files explicitly
the same name as the files in the working copy. While that's handy for
debugging purposes, it also makes the wc extremely fragile. What we
could have done is both less fragile *and* more efficient:
[1:52pm] ehu: gstein_: since we need to write out the entries file
anyway (ie, since we need to update our administration anyway), it's
more efficient to store the new filename of the file to be used as the
base *after the transaction completes* than to rename the file. Saves
many disk-accesses in order to rename every updated/checked out file.
Well, my current plan is to write all base text files in a multi-level
directory structure using their sha-1 hash values as the filename, and
as the components in the directory tree. So you'd have something like:
~/.subversion/bases/5a/78/f2/5a78f2ee5e6b4b0d3255bfef95601890afd80709
The file will get written, then never touched again (except to be
removed when all refs go away). The only thing that will change is the
metadata pointing at the file, and that is stored in a sqlite
database. No renames. No moving around in various directories. Just
drop it in, and go.
Note that if people keep the /bases/ directory in their home dir, then
the bases will be shared across ALL working copies. If you go to check
out a second WC, or maybe a branch, or something... it should go
*really* fast. We won't have to pull any bases from the server -- only
the changes specific to that branch (which should be deltas, anyways,
so therefore small). Most of the files will be copied out of the bases
directory into the new WC.
Debugging may be a bit more difficult, but it should be very easy to
write a tool to look in the sqlite database and provide a pointer to
the right base (i.e. python 2.5 comes with sqlite; or a bash script
using the sqlite cmdline tool).
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Karl Fogel <kf...@red-bean.com>.
"Greg Stein" <gs...@gmail.com> writes:
> Well, my current plan is to write all base text files in a multi-level
> directory structure using their sha-1 hash values as the filename, and
> as the components in the directory tree. So you'd have something like:
>
> ~/.subversion/bases/5a/78/f2/5a78f2ee5e6b4b0d3255bfef95601890afd80709
>
> The file will get written, then never touched again (except to be
> removed when all refs go away). The only thing that will change is the
> metadata pointing at the file, and that is stored in a sqlite
> database. No renames. No moving around in various directories. Just
> drop it in, and go.
>
> Note that if people keep the /bases/ directory in their home dir, then
> the bases will be shared across ALL working copies. If you go to check
> out a second WC, or maybe a branch, or something... it should go
> *really* fast. We won't have to pull any bases from the server -- only
> the changes specific to that branch (which should be deltas, anyways,
> so therefore small). Most of the files will be copied out of the bases
> directory into the new WC.
Which, ironically, would mean we'd have solved issue #2286 for working
copies before solving it for repositories.
> Debugging may be a bit more difficult, but it should be very easy to
> write a tool to look in the sqlite database and provide a pointer to
> the right base (i.e. python 2.5 comes with sqlite; or a bash script
> using the sqlite cmdline tool).
Yes, and I'd happily whip up an Emacs interface (or interfaces) to such
a tool :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Sep 15, 2008 at 4:55 AM, Talden <ta...@gmail.com> wrote:
>...
> Take the approach that Bazaar does with shared repositories. Users
> either create a standalone working-copy that houses its own bases or
> create a local repo which houses the bases for any enclosed
> working-copies.
Good idea, and it seems doable. We find the metadata by scanning
upwards from the target directory. No reason to disallow metadata
sitting a directory above a wc root. We'll still auto-find it, rather
than have to rely on a config/envvar.
> EG 4 related working copies all arbitrarily nested under an enclosing
> local-bases repository.
>
> c:/wc/myproject/
> .svn/bases/...
> mainlines/
> kea/
> .svn/...
> kiwi/...
> .svn/...
> branches/
> bug-12345/
> .svn/...
> story-23456/
> .svn/...
Note that the .svn/ directories won't be present. Everything will be
in myproject/.svn/. The bases subdir and a file named like
./svn/wc-metadata.sql3
To establish a layout like the above, the user would issue a command
something like:
C:\> svn co http://example.com/path \wc\myproject\kiwi
--metadata=c:\wc\myproject
IOW, they specify a specific directory, and (hey!) it just happens to
reside in the upwards-scan path.
> You can still use reference-counting to assist in purging bases but
> also offer a command to do a scavenger hunt for bases not really
> referenced - such bases could be scheduled for deletion in a delayed
> FIFO queue.
Well, I dunno that a queue is gonna save much over just deleting them
as part of the command. And rather than intro a new one, I think we'd
just use "svn cleanup".
> Not as convenient as being able to separate it off onto separate
> spindles but still a handy layout.
Yup. Good for organizing a related set of working copies.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Talden <ta...@gmail.com>.
> That's a good point. I was thinking that it wouldn't be a big deal...
> svn can easily track the references. But I guess not so much if you
> just blast the WC out from under it :-P
Take the approach that Bazaar does with shared repositories. Users
either create a standalone working-copy that houses its own bases or
create a local repo which houses the bases for any enclosed
working-copies.
EG 4 related working copies all arbitrarily nested under an enclosing
local-bases repository.
c:/wc/myproject/
.svn/bases/...
mainlines/
kea/
.svn/...
kiwi/...
.svn/...
branches/
bug-12345/
.svn/...
story-23456/
.svn/...
You can still use reference-counting to assist in purging bases but
also offer a command to do a scavenger hunt for bases not really
referenced - such bases could be scheduled for deletion in a delayed
FIFO queue.
Not as convenient as being able to separate it off onto separate
spindles but still a handy layout.
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Mattias Engdegård <ma...@virtutech.se>.
>We could have the wc record itself every time some svn command accesses
>it -- is this what you plan?
That is potentially expensive and complex, turning a read-only
operation into a read/write one; rarely a good idea. It also
introduces more points of failure.
Otherwise, available options seem to be:
1. Keep strict reference counts (or reverse references) in the shared
base, and tell the user to only use Subversion-approved means of WC
removal, or else.
Variants:
a. Force trees sharing the same text-base to live within a single
hierarchy (Bazaar). Not sure how that helps, other than limiting
the scope for exhaustive search for references.
b. Keep conservative reference counts (that may overstate the need for
each file), and accept a certain leakage.
2. Don't keep reference counts but treat the text-base tree as the
cache it really is, and purge old entries once it exceeds a certain
user-specified size.
Disconnected operation is a minor problem. A command to "please ensure
that this WC is fully backed in my text-base" might work.
3. Forget about the idea, seductive as it is, for now at least.
(And the new WC _will_ be done quicker without holding it hostage to
a shared text-base facility.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by David O'Shea <da...@s3group.com>.
On 15/09/2008 13:17, Greg Stein wrote:
> On Mon, Sep 15, 2008 at 5:07 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> Greg Stein wrote on Mon, 15 Sep 2008 at 04:29 -0700:
>>> That's a good point. I was thinking that it wouldn't be a big deal...
>>> svn can easily track the references. But I guess not so much if you
>>> just blast the WC out from under it :-P
>> And what if, rather than blasted away, the WC was renamed or duplicated
>> (causing the reference count to be lower than actuality)? How do you
>> fix the reference counts then?
>
> If it is renamed, then you've just "lost" your metadata. The metadata
> is tied to an absolute path.
>
> It seems possible to have some admin command to notify svn that you
> renamed the directory, but I'd rather just say "don't do that, or keep
> the metadata inside the WC if you're gonna move it around." Same thing
> goes for copies.
I find it useful to be able to rename a WC after doing a switch - it
would be a shame if this were no longer possible.
Regards,
David.
--
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: communications@s3group.com.
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2008-09-17 04:29:34 -0700, Greg Stein wrote:
> If there are no .svn directories in your working copy, then it looks
> like any other directory. The only way for svn to know it's a working
> copy is to hold a reference to its absolute path.
>
> That said, we've also been discussing how to drop a unique identify
> into (say) .svn/wc-id at the root of your working copy. There are some
> potential issues with that, however. When svn sees the working copy at
> a new path, it won't necessarily know if it was simply moved or
> copied, and (thus) how to handle the metadata that it has recorded for
> that working copy.
How about allowing paths relative to some environment variable
(e.g., $HOME)?
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Greg Stein <gs...@gmail.com>.
I made a change yesterday to our sqlite support to enable readonly
operation. I'll work on ensuring it propagates out to the cmdline.
Cheers,
-g
On Sep 18, 2008, at 13:43, Martin Furter <mf...@rola.ch> wrote:
>
>
> On Thu, 18 Sep 2008, Miha Vitorovic wrote:
>
>> dglasser@gmail.com wrote on 17.09.2008 16:07:24:
>>
>>> As this thread has gone on, I think I've lost track of the
>>> motivation
>>> for centralizing the metadata beyond just the working copy root. I
>>> understand wanting to be able to (optionally) centralize and share
>>> the
>>> blob-store (since file contents/etc are likely to be shared between
>>> multiple working copies), but what is the gain of combining the
>>> actual
>>> working copy metadata itself? (More than "you can control where it
>>> sits", which you can also do by replacing the .svn directory with a
>>> symlink.)
>>
>> As I explained in another thread, there may be cases where the source
>> files aren't on an actual disk and you can't create folders there.
>> It has
>> the potential to bring Subversion to places where it wasn't before.
>
> What do you mean with 'not on an actual disk'?
> You have them on a read-only filesystem?
> I also have working copies on read-only filesystems (NFS mounts to
> be able to compile on different machines), though I only need
> svnversion and 'svn info' there.
> I hope read-only operations will still be possible on read-only
> working copies.
>
> Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Martin Furter <mf...@rola.ch>.
On Thu, 18 Sep 2008, Miha Vitorovic wrote:
> dglasser@gmail.com wrote on 17.09.2008 16:07:24:
>
>> As this thread has gone on, I think I've lost track of the motivation
>> for centralizing the metadata beyond just the working copy root. I
>> understand wanting to be able to (optionally) centralize and share the
>> blob-store (since file contents/etc are likely to be shared between
>> multiple working copies), but what is the gain of combining the actual
>> working copy metadata itself? (More than "you can control where it
>> sits", which you can also do by replacing the .svn directory with a
>> symlink.)
>
> As I explained in another thread, there may be cases where the source
> files aren't on an actual disk and you can't create folders there. It has
> the potential to bring Subversion to places where it wasn't before.
What do you mean with 'not on an actual disk'?
You have them on a read-only filesystem?
I also have working copies on read-only filesystems (NFS mounts to be able
to compile on different machines), though I only need svnversion and
'svn info' there.
I hope read-only operations will still be possible on read-only working
copies.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Miha Vitorovic <mv...@nil.si>.
Greg Stein <gs...@gmail.com> wrote on 18.09.2008 14:39:04:
> Just to be clear, Miha: that is not a design goal of the WC rewrite,
> at this time. It will certainly be easier to do what you ask, but I
> don't plan to specifically enable it.
>
> Cheers,
> -g
I understand. I'm just bringing this up, so that hopefully you at least
leave the door open for future development, not close it now with a "bad"
design decision.
Br,
---
Miha Vitorovic
Inženir v tehničnem področju
Customer Support Engineer
NIL Data Communications, Tivolska cesta 48, 1000 Ljubljana, Slovenia
Phone +386 1 4746 500 Fax +386 1 4746 501 http://www.NIL.si
Re: Base text files, re: IRC chat
Posted by Greg Stein <gs...@gmail.com>.
Just to be clear, Miha: that is not a design goal of the WC rewrite,
at this time. It will certainly be easier to do what you ask, but I
don't plan to specifically enable it.
Cheers,
-g
On Sep 18, 2008, at 2:47, Miha Vitorovic <mv...@nil.si> wrote:
>
> dglasser@gmail.com wrote on 17.09.2008 16:07:24:
>
> > As this thread has gone on, I think I've lost track of the
> motivation
> > for centralizing the metadata beyond just the working copy root. I
> > understand wanting to be able to (optionally) centralize and share
> the
> > blob-store (since file contents/etc are likely to be shared between
> > multiple working copies), but what is the gain of combining the
> actual
> > working copy metadata itself? (More than "you can control where it
> > sits", which you can also do by replacing the .svn directory with a
> > symlink.)
>
> As I explained in another thread, there may be cases where the
> source files aren't on an actual disk and you can't create folders
> there. It has the potential to bring Subversion to places where it
> wasn't before.
>
> Br,
>
> ---
> Miha Vitorovic
> Inženir v tehničnem področju
> Customer Support Engineer
>
> NIL Data Communications, Tivolska cesta 48, 1000 Ljubljana,
> Slovenia
> Phone +386 1 4746 500 Fax +386 1 4746 501 http://www.NIL.si
>
Re: Base text files, re: IRC chat
Posted by Miha Vitorovic <mv...@nil.si>.
dglasser@gmail.com wrote on 17.09.2008 16:07:24:
> As this thread has gone on, I think I've lost track of the motivation
> for centralizing the metadata beyond just the working copy root. I
> understand wanting to be able to (optionally) centralize and share the
> blob-store (since file contents/etc are likely to be shared between
> multiple working copies), but what is the gain of combining the actual
> working copy metadata itself? (More than "you can control where it
> sits", which you can also do by replacing the .svn directory with a
> symlink.)
As I explained in another thread, there may be cases where the source
files aren't on an actual disk and you can't create folders there. It has
the potential to bring Subversion to places where it wasn't before.
Br,
---
Miha Vitorovic
Inženir v tehničnem področju
Customer Support Engineer
NIL Data Communications, Tivolska cesta 48, 1000 Ljubljana, Slovenia
Phone +386 1 4746 500 Fax +386 1 4746 501 http://www.NIL.si
Re: Base text files, re: IRC chat
Posted by David Glasser <gl...@davidglasser.net>.
I'm referring to a single person working in multiple working copies at
once: doing a huge checkout while working in a second wc, for example.
Not necessarily everyday behavior, but far more reasonable than the
other edge cases brought up in this thread.
--dave
On Thu, Sep 18, 2008 at 1:49 PM, Greg Stein <gs...@gmail.com> wrote:
> There are no concerns around concurrency. The typical working copy is used
> by only one person at a time. Same for a central datastore covering multiple
> working copies. For shared working copies, the potential for contention is
> ridiculously small.
>
> Regardless, SQLite will handle the concurrency issues.
>
> Cheers,
> -g
>
> On Sep 18, 2008, at 13:38, "David Glasser" <gl...@davidglasser.net> wrote:
>
>> I don't even know that "opening a single database" is an advantage: it
>> has implications for concurrency between operations on completely
>> separate working copies.
>>
>> --dave
>>
>> On Wed, Sep 17, 2008 at 11:01 AM, Greg Stein <gs...@gmail.com> wrote:
>>>
>>> Combining/sharing the blob-store and the metadata that defines it is
>>> the biggest one. But we could potentially share all data about the
>>> BASE tree. If the same node <uuid, path, rev> occurs in multiple
>>> working copies, then information about the text and props can be
>>> shared.
>>>
>>> I believe and agree with you that there is little benefit in putting
>>> all the WORKING trees into one database, beyond the small advantage of
>>> opening a single database.
>>>
>>> Cheers,
>>> -g
>>>
>>> On Wed, Sep 17, 2008 at 7:07 AM, David Glasser <gl...@davidglasser.net>
>>> wrote:
>>>>
>>>> On Wed, Sep 17, 2008 at 7:29 AM, Greg Stein <gs...@gmail.com> wrote:
>>>>>
>>>>> On Wed, Sep 17, 2008 at 3:34 AM, Vincent Lefevre
>>>>> <vi...@vinc17.org> wrote:
>>>>>>
>>>>>> On 2008-09-15 05:17:25 -0700, Greg Stein wrote:
>>>>>>>
>>>>>>> If it is renamed, then you've just "lost" your metadata. The metadata
>>>>>>> is tied to an absolute path.
>>>>>>
>>>>>> An absolute path? This would be annoying because the path to my NFS
>>>>>> home depends on the machine from which I have access.
>>>>>
>>>>> If there are no .svn directories in your working copy, then it looks
>>>>> like any other directory. The only way for svn to know it's a working
>>>>> copy is to hold a reference to its absolute path.
>>>>>
>>>>> That said, we've also been discussing how to drop a unique identify
>>>>> into (say) .svn/wc-id at the root of your working copy. There are some
>>>>> potential issues with that, however. When svn sees the working copy at
>>>>> a new path, it won't necessarily know if it was simply moved or
>>>>> copied, and (thus) how to handle the metadata that it has recorded for
>>>>> that working copy.
>>>>>
>>>>> In your situation, you'd simply want to keep the metadata in the
>>>>> wcroot, rather than a centralized location. If all the data is in
>>>>> wcroot/.svn/, then svn will not worry about the absolute path at all.
>>>>
>>>> As this thread has gone on, I think I've lost track of the motivation
>>>> for centralizing the metadata beyond just the working copy root. I
>>>> understand wanting to be able to (optionally) centralize and share the
>>>> blob-store (since file contents/etc are likely to be shared between
>>>> multiple working copies), but what is the gain of combining the actual
>>>> working copy metadata itself? (More than "you can control where it
>>>> sits", which you can also do by replacing the .svn directory with a
>>>> symlink.)
>>>>
>>>> --dave
>>>>
>>>> --
>>>> David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
>>>>
>>>
>>
>>
>>
>> --
>> David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
>
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Greg Stein <gs...@gmail.com>.
There are no concerns around concurrency. The typical working copy is
used by only one person at a time. Same for a central datastore
covering multiple working copies. For shared working copies, the
potential for contention is ridiculously small.
Regardless, SQLite will handle the concurrency issues.
Cheers,
-g
On Sep 18, 2008, at 13:38, "David Glasser" <gl...@davidglasser.net>
wrote:
> I don't even know that "opening a single database" is an advantage: it
> has implications for concurrency between operations on completely
> separate working copies.
>
> --dave
>
> On Wed, Sep 17, 2008 at 11:01 AM, Greg Stein <gs...@gmail.com> wrote:
>> Combining/sharing the blob-store and the metadata that defines it is
>> the biggest one. But we could potentially share all data about the
>> BASE tree. If the same node <uuid, path, rev> occurs in multiple
>> working copies, then information about the text and props can be
>> shared.
>>
>> I believe and agree with you that there is little benefit in putting
>> all the WORKING trees into one database, beyond the small advantage
>> of
>> opening a single database.
>>
>> Cheers,
>> -g
>>
>> On Wed, Sep 17, 2008 at 7:07 AM, David Glasser <glasser@davidglasser.net
>> > wrote:
>>> On Wed, Sep 17, 2008 at 7:29 AM, Greg Stein <gs...@gmail.com>
>>> wrote:
>>>> On Wed, Sep 17, 2008 at 3:34 AM, Vincent Lefevre <vincent+svn@vinc17.org
>>>> > wrote:
>>>>> On 2008-09-15 05:17:25 -0700, Greg Stein wrote:
>>>>>> If it is renamed, then you've just "lost" your metadata. The
>>>>>> metadata
>>>>>> is tied to an absolute path.
>>>>>
>>>>> An absolute path? This would be annoying because the path to my
>>>>> NFS
>>>>> home depends on the machine from which I have access.
>>>>
>>>> If there are no .svn directories in your working copy, then it
>>>> looks
>>>> like any other directory. The only way for svn to know it's a
>>>> working
>>>> copy is to hold a reference to its absolute path.
>>>>
>>>> That said, we've also been discussing how to drop a unique identify
>>>> into (say) .svn/wc-id at the root of your working copy. There are
>>>> some
>>>> potential issues with that, however. When svn sees the working
>>>> copy at
>>>> a new path, it won't necessarily know if it was simply moved or
>>>> copied, and (thus) how to handle the metadata that it has
>>>> recorded for
>>>> that working copy.
>>>>
>>>> In your situation, you'd simply want to keep the metadata in the
>>>> wcroot, rather than a centralized location. If all the data is in
>>>> wcroot/.svn/, then svn will not worry about the absolute path at
>>>> all.
>>>
>>> As this thread has gone on, I think I've lost track of the
>>> motivation
>>> for centralizing the metadata beyond just the working copy root. I
>>> understand wanting to be able to (optionally) centralize and share
>>> the
>>> blob-store (since file contents/etc are likely to be shared between
>>> multiple working copies), but what is the gain of combining the
>>> actual
>>> working copy metadata itself? (More than "you can control where it
>>> sits", which you can also do by replacing the .svn directory with a
>>> symlink.)
>>>
>>> --dave
>>>
>>> --
>>> David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
>>>
>>
>
>
>
> --
> David Glasser | glasser@davidglasser.net | http://
> www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by David Glasser <gl...@davidglasser.net>.
I don't even know that "opening a single database" is an advantage: it
has implications for concurrency between operations on completely
separate working copies.
--dave
On Wed, Sep 17, 2008 at 11:01 AM, Greg Stein <gs...@gmail.com> wrote:
> Combining/sharing the blob-store and the metadata that defines it is
> the biggest one. But we could potentially share all data about the
> BASE tree. If the same node <uuid, path, rev> occurs in multiple
> working copies, then information about the text and props can be
> shared.
>
> I believe and agree with you that there is little benefit in putting
> all the WORKING trees into one database, beyond the small advantage of
> opening a single database.
>
> Cheers,
> -g
>
> On Wed, Sep 17, 2008 at 7:07 AM, David Glasser <gl...@davidglasser.net> wrote:
>> On Wed, Sep 17, 2008 at 7:29 AM, Greg Stein <gs...@gmail.com> wrote:
>>> On Wed, Sep 17, 2008 at 3:34 AM, Vincent Lefevre <vi...@vinc17.org> wrote:
>>>> On 2008-09-15 05:17:25 -0700, Greg Stein wrote:
>>>>> If it is renamed, then you've just "lost" your metadata. The metadata
>>>>> is tied to an absolute path.
>>>>
>>>> An absolute path? This would be annoying because the path to my NFS
>>>> home depends on the machine from which I have access.
>>>
>>> If there are no .svn directories in your working copy, then it looks
>>> like any other directory. The only way for svn to know it's a working
>>> copy is to hold a reference to its absolute path.
>>>
>>> That said, we've also been discussing how to drop a unique identify
>>> into (say) .svn/wc-id at the root of your working copy. There are some
>>> potential issues with that, however. When svn sees the working copy at
>>> a new path, it won't necessarily know if it was simply moved or
>>> copied, and (thus) how to handle the metadata that it has recorded for
>>> that working copy.
>>>
>>> In your situation, you'd simply want to keep the metadata in the
>>> wcroot, rather than a centralized location. If all the data is in
>>> wcroot/.svn/, then svn will not worry about the absolute path at all.
>>
>> As this thread has gone on, I think I've lost track of the motivation
>> for centralizing the metadata beyond just the working copy root. I
>> understand wanting to be able to (optionally) centralize and share the
>> blob-store (since file contents/etc are likely to be shared between
>> multiple working copies), but what is the gain of combining the actual
>> working copy metadata itself? (More than "you can control where it
>> sits", which you can also do by replacing the .svn directory with a
>> symlink.)
>>
>> --dave
>>
>> --
>> David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
>>
>
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Greg Stein <gs...@gmail.com>.
Combining/sharing the blob-store and the metadata that defines it is
the biggest one. But we could potentially share all data about the
BASE tree. If the same node <uuid, path, rev> occurs in multiple
working copies, then information about the text and props can be
shared.
I believe and agree with you that there is little benefit in putting
all the WORKING trees into one database, beyond the small advantage of
opening a single database.
Cheers,
-g
On Wed, Sep 17, 2008 at 7:07 AM, David Glasser <gl...@davidglasser.net> wrote:
> On Wed, Sep 17, 2008 at 7:29 AM, Greg Stein <gs...@gmail.com> wrote:
>> On Wed, Sep 17, 2008 at 3:34 AM, Vincent Lefevre <vi...@vinc17.org> wrote:
>>> On 2008-09-15 05:17:25 -0700, Greg Stein wrote:
>>>> If it is renamed, then you've just "lost" your metadata. The metadata
>>>> is tied to an absolute path.
>>>
>>> An absolute path? This would be annoying because the path to my NFS
>>> home depends on the machine from which I have access.
>>
>> If there are no .svn directories in your working copy, then it looks
>> like any other directory. The only way for svn to know it's a working
>> copy is to hold a reference to its absolute path.
>>
>> That said, we've also been discussing how to drop a unique identify
>> into (say) .svn/wc-id at the root of your working copy. There are some
>> potential issues with that, however. When svn sees the working copy at
>> a new path, it won't necessarily know if it was simply moved or
>> copied, and (thus) how to handle the metadata that it has recorded for
>> that working copy.
>>
>> In your situation, you'd simply want to keep the metadata in the
>> wcroot, rather than a centralized location. If all the data is in
>> wcroot/.svn/, then svn will not worry about the absolute path at all.
>
> As this thread has gone on, I think I've lost track of the motivation
> for centralizing the metadata beyond just the working copy root. I
> understand wanting to be able to (optionally) centralize and share the
> blob-store (since file contents/etc are likely to be shared between
> multiple working copies), but what is the gain of combining the actual
> working copy metadata itself? (More than "you can control where it
> sits", which you can also do by replacing the .svn directory with a
> symlink.)
>
> --dave
>
> --
> David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Fwd: Base text files, re: IRC chat
Posted by Roo <ro...@gmail.com>.
---------- Forwarded message ----------
From: Roo <ro...@gmail.com>
Date: 2008/9/20
Subject: Re: Base text files, re: IRC chat
To: David Glasser <gl...@davidglasser.net>
2008/9/18 David Glasser <gl...@davidglasser.net>:
> As this thread has gone on, I think I've lost track of the motivation
> for centralizing the metadata beyond just the working copy root.
I recall reading in other threads that at least one enhancement would
require centralised metadata store to be implemented. I do not know if
that is the case, but wc-ng has me following these changes closely.
AIUI, Repo wide auto props, svn:ignore, svn:eol-style and other repo
wide configuration require wc-ng before they could be implemented.
Roo.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by David Glasser <gl...@davidglasser.net>.
On Wed, Sep 17, 2008 at 7:29 AM, Greg Stein <gs...@gmail.com> wrote:
> On Wed, Sep 17, 2008 at 3:34 AM, Vincent Lefevre <vi...@vinc17.org> wrote:
>> On 2008-09-15 05:17:25 -0700, Greg Stein wrote:
>>> If it is renamed, then you've just "lost" your metadata. The metadata
>>> is tied to an absolute path.
>>
>> An absolute path? This would be annoying because the path to my NFS
>> home depends on the machine from which I have access.
>
> If there are no .svn directories in your working copy, then it looks
> like any other directory. The only way for svn to know it's a working
> copy is to hold a reference to its absolute path.
>
> That said, we've also been discussing how to drop a unique identify
> into (say) .svn/wc-id at the root of your working copy. There are some
> potential issues with that, however. When svn sees the working copy at
> a new path, it won't necessarily know if it was simply moved or
> copied, and (thus) how to handle the metadata that it has recorded for
> that working copy.
>
> In your situation, you'd simply want to keep the metadata in the
> wcroot, rather than a centralized location. If all the data is in
> wcroot/.svn/, then svn will not worry about the absolute path at all.
As this thread has gone on, I think I've lost track of the motivation
for centralizing the metadata beyond just the working copy root. I
understand wanting to be able to (optionally) centralize and share the
blob-store (since file contents/etc are likely to be shared between
multiple working copies), but what is the gain of combining the actual
working copy metadata itself? (More than "you can control where it
sits", which you can also do by replacing the .svn directory with a
symlink.)
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Sep 17, 2008 at 3:34 AM, Vincent Lefevre <vi...@vinc17.org> wrote:
> On 2008-09-15 05:17:25 -0700, Greg Stein wrote:
>> If it is renamed, then you've just "lost" your metadata. The metadata
>> is tied to an absolute path.
>
> An absolute path? This would be annoying because the path to my NFS
> home depends on the machine from which I have access.
If there are no .svn directories in your working copy, then it looks
like any other directory. The only way for svn to know it's a working
copy is to hold a reference to its absolute path.
That said, we've also been discussing how to drop a unique identify
into (say) .svn/wc-id at the root of your working copy. There are some
potential issues with that, however. When svn sees the working copy at
a new path, it won't necessarily know if it was simply moved or
copied, and (thus) how to handle the metadata that it has recorded for
that working copy.
In your situation, you'd simply want to keep the metadata in the
wcroot, rather than a centralized location. If all the data is in
wcroot/.svn/, then svn will not worry about the absolute path at all.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2008-09-15 05:17:25 -0700, Greg Stein wrote:
> If it is renamed, then you've just "lost" your metadata. The metadata
> is tied to an absolute path.
An absolute path? This would be annoying because the path to my NFS
home depends on the machine from which I have access.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Miha Vitorovic <mv...@nil.si>.
"Greg Stein" <gs...@gmail.com> wrote on 17.09.2008 13:35:03:
> 2008/9/17 Miha Vitorovic <mv...@nil.si>:
> > I know I'm not a Subversion developer, but I hope I can contribute
some
> > thoughts...
>
> Absolutely! Your thoughts are most welcome.
>
> > I'd like to be able to use the new WC in places where the source
> > is not exactly "on disk", and thus does not have the ability to host a
> > mandatory .svn directory. So far the new WC seems to be developing in
that
> > direction. Or not?
>
> Correct. You can tell svn to store the metadata in a location of your
> choosing; specifically, outside of the WC. In this case, svn will know
> the WC by its absolute path and will not require any .svn directories
> to be present.
>
> That said: we've been talking about having a .svn subdir at the root
> of the WC that simply holds a unique identifier. This will allow svn
> to "repair" the link between the central metadata store and the WC if
> it gets moved or copied. I'd like to retain the no-.svn behavior as an
> option, but it will mean that a developer cannot move his WC without
> some extra work to tell svn about the move.
>
> > Greg, would it be possible to replace "absolute path in the meta data"
with
> > some arbitrary "signature" that would enable to link the meta data
with the
> > Working copy?
>
> The .svn/wc-id at the WC root will do this. Outside of that, there is
> no way to have a signature since any/all files in the WC may change
> and throw off any fingerprint of the WC. We have to have some kind of
> svn-private file that the user is not allowed to tweak in order to
> have a persistent signature/identifier for the WC.
Well, I've seen the mention of wcuuid in some other thread. Wouldn't that
be just what is needed? Maybe I should make myself clearer; I'm not
thinking about using a plain vanilla svn client, but rather extending an
existing/writing a new client. In this case it would be up to the client
to provide the correct signature that uniquely identifies a WC. I'm
explaining why I desire this in another message.
Br,
---
Miha Vitorovic
Inženir v tehničnem področju
Customer Support Engineer
NIL Data Communications, Tivolska cesta 48, 1000 Ljubljana, Slovenia
Phone +386 1 4746 500 Fax +386 1 4746 501 http://www.NIL.si
Re: Base text files, re: IRC chat
Posted by Greg Stein <gs...@gmail.com>.
2008/9/17 Miha Vitorovic <mv...@nil.si>:
> I know I'm not a Subversion developer, but I hope I can contribute some
> thoughts...
Absolutely! Your thoughts are most welcome.
> I'd like to be able to use the new WC in places where the source
> is not exactly "on disk", and thus does not have the ability to host a
> mandatory .svn directory. So far the new WC seems to be developing in that
> direction. Or not?
Correct. You can tell svn to store the metadata in a location of your
choosing; specifically, outside of the WC. In this case, svn will know
the WC by its absolute path and will not require any .svn directories
to be present.
That said: we've been talking about having a .svn subdir at the root
of the WC that simply holds a unique identifier. This will allow svn
to "repair" the link between the central metadata store and the WC if
it gets moved or copied. I'd like to retain the no-.svn behavior as an
option, but it will mean that a developer cannot move his WC without
some extra work to tell svn about the move.
> Greg, would it be possible to replace "absolute path in the meta data" with
> some arbitrary "signature" that would enable to link the meta data with the
> Working copy?
The .svn/wc-id at the WC root will do this. Outside of that, there is
no way to have a signature since any/all files in the WC may change
and throw off any fingerprint of the WC. We have to have some kind of
svn-private file that the user is not allowed to tweak in order to
have a persistent signature/identifier for the WC.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Mon, 15 Sep 2008 at 21:41 +0200:
> On Mon, Sep 15, 2008 at 10:21:46PM +0300, Daniel Shahaf wrote:
> > Stefan Sperling wrote on Mon, 15 Sep 2008 at 21:06 +0200:
> > > Hmmm... so maybe requiring user interaction to sync working
> > > copies with the central meta data store is indeed the way to go?
> > > I don't like this, but I acknowledge that automatically managing
> > > moved/copied working copies may be non-trivial to implement.
> > >
> >
> > Agreed, I conjecture we'll want manual control anyway (even if some sort
> > of magic wcuuid system is used). With all of us (except Greg :)) moving
> > and rsyncing wc's all the time, keeping track of it might not be easy.
>
> Yes, of course, a manual system is needed. It was not my intention
> to imply that it wouldn't be needed.
>
+1
> But if we can handle some of this stuff automatically, why not?
>
It was not my intention to imply that wc UUIDs and related magic
wouldn't be needed. :)
> > I don't view this as an extension to 'svn mv/cp', though -- I consider
> > a separate command that just tells svn "Here is a wc, add it" or "Here
> > was a wc, forget it". That's so I can use tar or rsync or ... to move
> > or duplicate my wc's.
>
> Let's just have the manual way first and try to introduce some
> form of automatic working copy tracking later. Having the concept
> of unique IDs for working copies would probably be a nice feature
> in any case.
I already imagine users running 'svnadmin setuuid' after we tell them to
run 'svn setuuid'. :)
Seriously. Even without UUIDs, just having a list of all WCs around
should should by itself enable some nice things, too.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Sep 15, 2008 at 10:21:46PM +0300, Daniel Shahaf wrote:
> Stefan Sperling wrote on Mon, 15 Sep 2008 at 21:06 +0200:
> > The only problem I'm seeing here is that needing access to
> > another working copy to determine whether the current working
> > copy is a copy is quite fragile. The other working copy
> > may be on a drive that's unmounted or horribly slow... :-/
> >
>
> We don't need access to the other working copy -- we can store both its
> path and its wcuuid in the centralised store.
Oh, good point :)
> > Hmmm... so maybe requiring user interaction to sync working
> > copies with the central meta data store is indeed the way to go?
> > I don't like this, but I acknowledge that automatically managing
> > moved/copied working copies may be non-trivial to implement.
> >
>
> Agreed, I conjecture we'll want manual control anyway (even if some sort
> of magic wcuuid system is used). With all of us (except Greg :)) moving
> and rsyncing wc's all the time, keeping track of it might not be easy.
Yes, of course, a manual system is needed. It was not my intention
to imply that it wouldn't be needed.
But if we can handle some of this stuff automatically, why not?
> I don't view this as an extension to 'svn mv/cp', though -- I consider
> a separate command that just tells svn "Here is a wc, add it" or "Here
> was a wc, forget it". That's so I can use tar or rsync or ... to move
> or duplicate my wc's.
Let's just have the manual way first and try to introduce some
form of automatic working copy tracking later. Having the concept
of unique IDs for working copies would probably be a nice feature
in any case.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Blair Zajac <bl...@orcaware.com>.
Stefan Sperling wrote:
> On Mon, Sep 15, 2008 at 01:10:14PM -0400, Karl Fogel wrote:
>> Daniel Shahaf <d....@daniel.shahaf.name> writes:
>>> Karl Fogel wrote on Mon, 15 Sep 2008 at 12:18 -0400:
>>>> 1. The metadata knows where the working copy/copies live, by absolute
>>>> path, as Greg says.
>>>>
>>>> 2. If you plain mv or cp a working copy, it stops working, BUT...
>>>>
>>>> 3. ...the error message from Subversion points out that the working
>>>> copy may have been mv'd or cp'd, and offers a command to
>>>> "re-register" it with the metadata store. This command is the
>>>> metadata store's chance to clean up its reference counts
>>>> w.r.t. that working copy.
>>> ... and also offers another command to un-register the previous location.
>> I was thinking the same command would do both. That is, it would gather
>> all the knowledge it could, from inspection and (perhaps) from the user,
>> and DTRT.
>>
>>> And a command to list all WCs it knows about, maybe (so you can figure out
>>> what needs to be unregistered).
>> Urgk. Well, let's see if we really need that one first.
>
> I fail to see what's wrong with a mandatory .svn at the root of
> a working copy pointing to a meta data store to handle the
> moved-working-copy use case.
Don't we still want one to tell when you've moved up and out of a wc?
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Greg Stein <gs...@gmail.com>.
Minimal subcommands has been a design point since inception. Keeping
the count low makes svn more approachable.
But I'm not really worried at this point. That is a bikeshed to paint
later...
Cheers,
-g
On Sep 15, 2008, at 17:09, Stefan Sperling <st...@elego.de> wrote:
> On Mon, Sep 15, 2008 at 04:26:32PM -0400, Greg Stein wrote:
>> Didn't say it was the best idea :-)
>>
>> Main point is to avoid new subcommands if at all possible.
>
> Why? I'd say let's try to focus on creating an intuitively
> usable program. If a new subcommand is needed for that, so be it.
>
> And having 'svn wc' as a subcommand to manage working copies
> would be hilarious :)
> (I can't think of a better name right now, but 'svn workingcopy'
> is too long.)
>
> Stefan
>
> ---------------------------------------------------------------------
> 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: Base text files, re: IRC chat
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Sep 15, 2008 at 04:26:32PM -0400, Greg Stein wrote:
> Didn't say it was the best idea :-)
>
> Main point is to avoid new subcommands if at all possible.
Why? I'd say let's try to focus on creating an intuitively
usable program. If a new subcommand is needed for that, so be it.
And having 'svn wc' as a subcommand to manage working copies
would be hilarious :)
(I can't think of a better name right now, but 'svn workingcopy'
is too long.)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Greg Stein <gs...@gmail.com>.
Didn't say it was the best idea :-)
Main point is to avoid new subcommands if at all possible.
On Sep 15, 2008, at 16:15, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Greg Stein wrote on Mon, 15 Sep 2008 at 15:42 -0400:
>> I'm back to emailing via iPhone while driving... livin'
>> dangerously :-P ...
>> but abbreviated responses for now.
>>
>> Each wc will already have a uuid as a natural outgrowth of a SQL
>> table that
>> records all wc's. It is just the auto-generated primary key.
>>
>> I had already planned to drop that into .svn/wc-id at the wcroot to
>> identify
>> the wc.
>>
>> Rather than add new subcommands, I think a flag like --wc-local to
>> mv/cp/rm.
>>
>
> So they can operate either in the versioned filesystem space or in
> the OS
> filesystem space? We'll easily earn confused users this way, I think.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Greg Stein wrote on Mon, 15 Sep 2008 at 15:42 -0400:
> I'm back to emailing via iPhone while driving... livin' dangerously :-P ...
> but abbreviated responses for now.
>
> Each wc will already have a uuid as a natural outgrowth of a SQL table that
> records all wc's. It is just the auto-generated primary key.
>
> I had already planned to drop that into .svn/wc-id at the wcroot to identify
> the wc.
>
> Rather than add new subcommands, I think a flag like --wc-local to mv/cp/rm.
>
So they can operate either in the versioned filesystem space or in the OS
filesystem space? We'll easily earn confused users this way, I think.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Greg Stein <gs...@gmail.com>.
I'm back to emailing via iPhone while driving... livin' dangerously :-
P ... but abbreviated responses for now.
Each wc will already have a uuid as a natural outgrowth of a SQL table
that records all wc's. It is just the auto-generated primary key.
I had already planned to drop that into .svn/wc-id at the wcroot to
identify the wc.
Rather than add new subcommands, I think a flag like --wc-local to mv/
cp/rm.
Cheers,
-g
On Sep 15, 2008, at 15:21, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Stefan Sperling wrote on Mon, 15 Sep 2008 at 21:06 +0200:
>> On Mon, Sep 15, 2008 at 09:03:44PM +0300, Daniel Shahaf wrote:
>>> Stefan Sperling wrote on Mon, 15 Sep 2008 at 19:43 +0200:
>>>> I fail to see what's wrong with a mandatory .svn at the root of
>>>> a working copy
>>>
>>> +1 on this part of the sentence...
>>>
>>>> pointing to a meta data store to handle the
>>>> moved-working-copy use case.
>>>>
>>>
>>> Moving the wc won't update the reference in the centralised metadata
>>> storage to the wc?
>>
>> Huh. I must admit that I actually don't have a waterproof idea
>> how to automatically update the central store in this case :(
>>
>> Trail of thought:
>>
>> If we wanted to automatically tie moved and copied working
>> copies back to a central meta data store, we could have some
>> API function all callers have to go through to get at the
>> working copy (such a function might even already exist).
>>
>> We would need UUIDs for working copies to make this work.
>> Keying working copies by their absolute path alone wouldn't
>> cut it.
>>
>> When a working copy which points to a meta data store that
>> expects the working copy to be at a different path than it
>> currently occupies, and there is no working copy anymore at
>> the old path, then the meta data store can remember the new
>> location of the working copy automatically.
>>
>> In case of a UUID clash, i.e. when a working copy with a
>> matching UUID is still present at the old location, we could
>> generate a new UUID for the new (and presumably copied) working
>> copy.
>>
>> The only problem I'm seeing here is that needing access to
>> another working copy to determine whether the current working
>> copy is a copy is quite fragile. The other working copy
>> may be on a drive that's unmounted or horribly slow... :-/
>>
>
> We don't need access to the other working copy -- we can store both
> its
> path and its wcuuid in the centralised store.
>
>> Hmmm... so maybe requiring user interaction to sync working
>> copies with the central meta data store is indeed the way to go?
>> I don't like this, but I acknowledge that automatically managing
>> moved/copied working copies may be non-trivial to implement.
>>
>
> Agreed, I conjecture we'll want manual control anyway (even if some
> sort
> of magic wcuuid system is used). With all of us (except Greg :))
> moving
> and rsyncing wc's all the time, keeping track of it might not be easy.
>
> I don't view this as an extension to 'svn mv/cp', though -- I consider
> a separate command that just tells svn "Here is a wc, add it" or "Here
> was a wc, forget it". That's so I can use tar or rsync or ... to move
> or duplicate my wc's.
>
>> Stefan
>
> ---------------------------------------------------------------------
> 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: Base text files, re: IRC chat
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Mon, 15 Sep 2008 at 21:06 +0200:
> On Mon, Sep 15, 2008 at 09:03:44PM +0300, Daniel Shahaf wrote:
> > Stefan Sperling wrote on Mon, 15 Sep 2008 at 19:43 +0200:
> > > I fail to see what's wrong with a mandatory .svn at the root of
> > > a working copy
> >
> > +1 on this part of the sentence...
> >
> > > pointing to a meta data store to handle the
> > > moved-working-copy use case.
> > >
> >
> > Moving the wc won't update the reference in the centralised metadata
> > storage to the wc?
>
> Huh. I must admit that I actually don't have a waterproof idea
> how to automatically update the central store in this case :(
>
> Trail of thought:
>
> If we wanted to automatically tie moved and copied working
> copies back to a central meta data store, we could have some
> API function all callers have to go through to get at the
> working copy (such a function might even already exist).
>
> We would need UUIDs for working copies to make this work.
> Keying working copies by their absolute path alone wouldn't
> cut it.
>
> When a working copy which points to a meta data store that
> expects the working copy to be at a different path than it
> currently occupies, and there is no working copy anymore at
> the old path, then the meta data store can remember the new
> location of the working copy automatically.
>
> In case of a UUID clash, i.e. when a working copy with a
> matching UUID is still present at the old location, we could
> generate a new UUID for the new (and presumably copied) working
> copy.
>
> The only problem I'm seeing here is that needing access to
> another working copy to determine whether the current working
> copy is a copy is quite fragile. The other working copy
> may be on a drive that's unmounted or horribly slow... :-/
>
We don't need access to the other working copy -- we can store both its
path and its wcuuid in the centralised store.
> Hmmm... so maybe requiring user interaction to sync working
> copies with the central meta data store is indeed the way to go?
> I don't like this, but I acknowledge that automatically managing
> moved/copied working copies may be non-trivial to implement.
>
Agreed, I conjecture we'll want manual control anyway (even if some sort
of magic wcuuid system is used). With all of us (except Greg :)) moving
and rsyncing wc's all the time, keeping track of it might not be easy.
I don't view this as an extension to 'svn mv/cp', though -- I consider
a separate command that just tells svn "Here is a wc, add it" or "Here
was a wc, forget it". That's so I can use tar or rsync or ... to move
or duplicate my wc's.
> Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Greg Stein <gs...@gmail.com>.
The datastore (wc_db.h) already has a function you must call to open a
handle for datastore operations. That is the point where we locate the
metadata corresponding to the specified wc directory. It can easily
deal with apparent changes to wc's.
On Sep 15, 2008, at 15:06, Stefan Sperling <st...@elego.de> wrote:
> On Mon, Sep 15, 2008 at 09:03:44PM +0300, Daniel Shahaf wrote:
>> Stefan Sperling wrote on Mon, 15 Sep 2008 at 19:43 +0200:
>>> I fail to see what's wrong with a mandatory .svn at the root of
>>> a working copy
>>
>> +1 on this part of the sentence...
>>
>>> pointing to a meta data store to handle the
>>> moved-working-copy use case.
>>>
>>
>> Moving the wc won't update the reference in the centralised metadata
>> storage to the wc?
>
> Huh. I must admit that I actually don't have a waterproof idea
> how to automatically update the central store in this case :(
>
> Trail of thought:
>
> If we wanted to automatically tie moved and copied working
> copies back to a central meta data store, we could have some
> API function all callers have to go through to get at the
> working copy (such a function might even already exist).
>
> We would need UUIDs for working copies to make this work.
> Keying working copies by their absolute path alone wouldn't
> cut it.
>
> When a working copy which points to a meta data store that
> expects the working copy to be at a different path than it
> currently occupies, and there is no working copy anymore at
> the old path, then the meta data store can remember the new
> location of the working copy automatically.
>
> In case of a UUID clash, i.e. when a working copy with a
> matching UUID is still present at the old location, we could
> generate a new UUID for the new (and presumably copied) working
> copy.
>
> The only problem I'm seeing here is that needing access to
> another working copy to determine whether the current working
> copy is a copy is quite fragile. The other working copy
> may be on a drive that's unmounted or horribly slow... :-/
>
> Hmmm... so maybe requiring user interaction to sync working
> copies with the central meta data store is indeed the way to go?
> I don't like this, but I acknowledge that automatically managing
> moved/copied working copies may be non-trivial to implement.
>
> Stefan
>
> ---------------------------------------------------------------------
> 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: Base text files, re: IRC chat
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Sep 15, 2008 at 09:03:44PM +0300, Daniel Shahaf wrote:
> Stefan Sperling wrote on Mon, 15 Sep 2008 at 19:43 +0200:
> > I fail to see what's wrong with a mandatory .svn at the root of
> > a working copy
>
> +1 on this part of the sentence...
>
> > pointing to a meta data store to handle the
> > moved-working-copy use case.
> >
>
> Moving the wc won't update the reference in the centralised metadata
> storage to the wc?
Huh. I must admit that I actually don't have a waterproof idea
how to automatically update the central store in this case :(
Trail of thought:
If we wanted to automatically tie moved and copied working
copies back to a central meta data store, we could have some
API function all callers have to go through to get at the
working copy (such a function might even already exist).
We would need UUIDs for working copies to make this work.
Keying working copies by their absolute path alone wouldn't
cut it.
When a working copy which points to a meta data store that
expects the working copy to be at a different path than it
currently occupies, and there is no working copy anymore at
the old path, then the meta data store can remember the new
location of the working copy automatically.
In case of a UUID clash, i.e. when a working copy with a
matching UUID is still present at the old location, we could
generate a new UUID for the new (and presumably copied) working
copy.
The only problem I'm seeing here is that needing access to
another working copy to determine whether the current working
copy is a copy is quite fragile. The other working copy
may be on a drive that's unmounted or horribly slow... :-/
Hmmm... so maybe requiring user interaction to sync working
copies with the central meta data store is indeed the way to go?
I don't like this, but I acknowledge that automatically managing
moved/copied working copies may be non-trivial to implement.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Mon, 15 Sep 2008 at 19:43 +0200:
> On Mon, Sep 15, 2008 at 01:10:14PM -0400, Karl Fogel wrote:
> > Daniel Shahaf <d....@daniel.shahaf.name> writes:
> > > Karl Fogel wrote on Mon, 15 Sep 2008 at 12:18 -0400:
> > >> 1. The metadata knows where the working copy/copies live, by absolute
> > >> path, as Greg says.
> > >>
> > >> 2. If you plain mv or cp a working copy, it stops working, BUT...
> > >>
> > >> 3. ...the error message from Subversion points out that the working
> > >> copy may have been mv'd or cp'd, and offers a command to
> > >> "re-register" it with the metadata store. This command is the
> > >> metadata store's chance to clean up its reference counts
> > >> w.r.t. that working copy.
> > >
> > > ... and also offers another command to un-register the previous location.
> >
> > I was thinking the same command would do both. That is, it would gather
> > all the knowledge it could, from inspection and (perhaps) from the user,
> > and DTRT.
> >
Right: if it records all WCs it knows about, then we don't need a command
"unregister wc X" -- we just need a command "unregister all non-existing
wc's". (What Greg suggested originally...)
> > > And a command to list all WCs it knows about, maybe (so you can figure out
> > > what needs to be unregistered).
> >
> > Urgk. Well, let's see if we really need that one first.
>
> I fail to see what's wrong with a mandatory .svn at the root of
> a working copy
+1 on this part of the sentence...
> pointing to a meta data store to handle the
> moved-working-copy use case.
>
Moving the wc won't update the reference in the centralised metadata
storage to the wc?
> I'd say manual user intervention should only be required if the
> working copy was moved / copied, *and* the .svn directory in the
> root of a working copy does not point to a valid metadata store.
>
> For that case, only, the above plan sounds fine to me. But why make
> life difficult for users if we can simply equip the working copy
> with the necessary information it needs after having been moved?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Miha Vitorovic <mv...@nil.si>.
I know I'm not a Subversion developer, but I hope I can contribute some
thoughts... I'd like to be able to use the new WC in places where the
source is not exactly "on disk", and thus does not have the ability to
host a mandatory .svn directory. So far the new WC seems to be developing
in that direction. Or not?
Greg, would it be possible to replace "absolute path in the meta data"
with some arbitrary "signature" that would enable to link the meta data
with the Working copy?
Br,
---
Miha Vitorovic
Inženir v tehničnem področju
Customer Support Engineer
NIL Data Communications, Tivolska cesta 48, 1000 Ljubljana, Slovenia
Phone +386 1 4746 500 Fax +386 1 4746 501 http://www.NIL.si
Stefan Sperling <st...@elego.de> wrote on 15.09.2008 19:43:25:
> On Mon, Sep 15, 2008 at 01:10:14PM -0400, Karl Fogel wrote:
> > Daniel Shahaf <d....@daniel.shahaf.name> writes:
> > > Karl Fogel wrote on Mon, 15 Sep 2008 at 12:18 -0400:
> > >> 1. The metadata knows where the working copy/copies live, by
absolute
> > >> path, as Greg says.
> > >>
> > >> 2. If you plain mv or cp a working copy, it stops working,
BUT...
> > >>
> > >> 3. ...the error message from Subversion points out that the
working
> > >> copy may have been mv'd or cp'd, and offers a command to
> > >> "re-register" it with the metadata store. This command is
the
> > >> metadata store's chance to clean up its reference counts
> > >> w.r.t. that working copy.
> > >
> > > ... and also offers another command to un-register the previous
> location.
> >
> > I was thinking the same command would do both. That is, it would
gather
> > all the knowledge it could, from inspection and (perhaps) from the
user,
> > and DTRT.
Re: Base text files, re: IRC chat
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Sep 15, 2008 at 01:10:14PM -0400, Karl Fogel wrote:
> Daniel Shahaf <d....@daniel.shahaf.name> writes:
> > Karl Fogel wrote on Mon, 15 Sep 2008 at 12:18 -0400:
> >> 1. The metadata knows where the working copy/copies live, by absolute
> >> path, as Greg says.
> >>
> >> 2. If you plain mv or cp a working copy, it stops working, BUT...
> >>
> >> 3. ...the error message from Subversion points out that the working
> >> copy may have been mv'd or cp'd, and offers a command to
> >> "re-register" it with the metadata store. This command is the
> >> metadata store's chance to clean up its reference counts
> >> w.r.t. that working copy.
> >
> > ... and also offers another command to un-register the previous location.
>
> I was thinking the same command would do both. That is, it would gather
> all the knowledge it could, from inspection and (perhaps) from the user,
> and DTRT.
>
> > And a command to list all WCs it knows about, maybe (so you can figure out
> > what needs to be unregistered).
>
> Urgk. Well, let's see if we really need that one first.
I fail to see what's wrong with a mandatory .svn at the root of
a working copy pointing to a meta data store to handle the
moved-working-copy use case.
I'd say manual user intervention should only be required if the
working copy was moved / copied, *and* the .svn directory in the
root of a working copy does not point to a valid metadata store.
For that case, only, the above plan sounds fine to me. But why make
life difficult for users if we can simply equip the working copy
with the necessary information it needs after having been moved?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Karl Fogel <kf...@red-bean.com>.
Daniel Shahaf <d....@daniel.shahaf.name> writes:
> Karl Fogel wrote on Mon, 15 Sep 2008 at 12:18 -0400:
>> 1. The metadata knows where the working copy/copies live, by absolute
>> path, as Greg says.
>>
>> 2. If you plain mv or cp a working copy, it stops working, BUT...
>>
>> 3. ...the error message from Subversion points out that the working
>> copy may have been mv'd or cp'd, and offers a command to
>> "re-register" it with the metadata store. This command is the
>> metadata store's chance to clean up its reference counts
>> w.r.t. that working copy.
>
> ... and also offers another command to un-register the previous location.
I was thinking the same command would do both. That is, it would gather
all the knowledge it could, from inspection and (perhaps) from the user,
and DTRT.
> And a command to list all WCs it knows about, maybe (so you can figure out
> what needs to be unregistered).
Urgk. Well, let's see if we really need that one first.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Karl Fogel wrote on Mon, 15 Sep 2008 at 12:18 -0400:
> 1. The metadata knows where the working copy/copies live, by absolute
> path, as Greg says.
>
> 2. If you plain mv or cp a working copy, it stops working, BUT...
>
> 3. ...the error message from Subversion points out that the working
> copy may have been mv'd or cp'd, and offers a command to
> "re-register" it with the metadata store. This command is the
> metadata store's chance to clean up its reference counts
> w.r.t. that working copy.
... and also offers another command to un-register the previous location.
And a command to list all WCs it knows about, maybe (so you can figure out
what needs to be unregistered).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Karl Fogel <kf...@red-bean.com>.
Gunnar Dalsnes <ha...@online.no> writes:
> +1
>
> That a wc is fully operational on its own is very important, and I often move
> wc's around and it "just works". This was one of the reasons we moved from
> Vault.
I also move working copies around all the time.
But, I think there's a solution here:
1. The metadata knows where the working copy/copies live, by absolute
path, as Greg says.
2. If you plain mv or cp a working copy, it stops working, BUT...
3. ...the error message from Subversion points out that the working
copy may have been mv'd or cp'd, and offers a command to
"re-register" it with the metadata store. This command is the
metadata store's chance to clean up its reference counts
w.r.t. that working copy.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Re: Base text files, re: IRC chat
Posted by Talden <ta...@gmail.com>.
> This proposal sound like the most elagant and flexible one yet...
Sigh, if only I'd thought of it...
>> Other than a lack of means to clean-up, there's no reason we could not
>> support an argument to specify where the MD is rather than just look
>> for one in the parent path. That lack of clean-up could suck a bit
>> though.
> Why no ablility to cleanup? The MD knows what *should* be in a WC and
> can therefore cleanup?
>
> You can clean the MD automatically as well by issuing a command to the
> MD to search below itself and remove any missing MC (or restore them???)
If a WC is moved away from it's original location and not inside the
enclosing folder then the MD cannot find it and cannot know whether or
not to purge content.
Thinking about what we want to store in an MD though, perhaps this is
not a problem. If the MD knows the details of the WCs it holds
content for and that knowledge is updated by the WCs when they are
updated then perhaps the MD can intelligently manage it's content
without scanning its WCs (and therefore doesn't need to know where
they live).
The MD can also list the WC knowledge to assist users administering
their MD should they need to do so.
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: Base text files, re: IRC chat
Posted by "Thompson, Graeme (GE Infra, Aviation)" <Gr...@ge.com>.
> -----Original Message-----
> From: Talden [mailto:talden@gmail.com]
> Sent: 15 September 2008 22:56
> To: Gunnar Dalsnes
> Cc: dev@subversion.tigris.org
> Subject: Re: Base text files, re: IRC chat
>
> > That a wc is fully operational on its own is very
> important, and I often
> > move wc's around and it "just works". This was one of the
> reasons we moved
> > from Vault.
>
> Again, ala Bazaar.
>
> 1. Checking out a Working-Copy (WC) without a separate
> Meta-Data area (MD).
>
> Creates a .svn at the top of the WC that has all of the meta-data
> required for the WC to be completely standalone.
>
> 2. Checking out a WC into a folder that is enclosed by an MD.
>
> Creates a .svn at the top of the WC that knows to locate and place
> certain meta-data further up the path tree (no record of where,
> relative or absolute, so that they are independently movable).
>
> - Standalone WCs can be moved around freely.
>
> - WCs inside an MD can be moved around freely within the MD.
>
> - A command is needed to make a WC inside an MD into a standalone that
> can be moved outside of the enclosing MD.
>
> - A command is also needed to efficiently move a WC into an
> enclosing MD.
>
This proposal sound like the most elagant and flexible one yet...
It should be simple to implement if wcuuid were implemented as well.
> Other than a lack of means to clean-up, there's no reason we could not
> support an argument to specify where the MD is rather than just look
> for one in the parent path. That lack of clean-up could suck a bit
> though.
Why no ablility to cleanup? The MD knows what *should* be in a WC and
can therefore cleanup?
You can clean the MD automatically as well by issuing a command to the
MD to search below itself and remove any missing MC (or restore them???)
>
> --
> Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Gunnar Dalsnes <ha...@online.no>.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Talden wrote:
<blockquote
cite="mid:738d207f0809151456n4ff9d97bw29f293ebe181c308@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">That a wc is fully operational on its own is very important, and I often
move wc's around and it "just works". This was one of the reasons we moved
from Vault.
</pre>
</blockquote>
<pre wrap=""><!---->
Again, ala Bazaar.
1. Checking out a Working-Copy (WC) without a separate Meta-Data area (MD).
Creates a .svn at the top of the WC that has all of the meta-data
required for the WC to be completely standalone.
2. Checking out a WC into a folder that is enclosed by an MD.
Creates a .svn at the top of the WC that knows to locate and place
certain meta-data further up the path tree (no record of where,
relative or absolute, so that they are independently movable).
- Standalone WCs can be moved around freely.
- WCs inside an MD can be moved around freely within the MD.
</pre>
</blockquote>
Good plan!<br>
<blockquote
cite="mid:738d207f0809151456n4ff9d97bw29f293ebe181c308@mail.gmail.com"
type="cite">
<pre wrap="">- A command is needed to make a WC inside an MD into a standalone that
can be moved outside of the enclosing MD.
</pre>
</blockquote>
I see an additional option here: move wc out of MD as standalone or
move out as referencing wc (with abs path to MD). And off course, a
referencing wc can be initially created outside the MD (must specify
path to MD):-)
<blockquote
cite="mid:738d207f0809151456n4ff9d97bw29f293ebe181c308@mail.gmail.com"
type="cite">
<pre wrap="">
- A command is also needed to efficiently move a WC into an enclosing MD.
</pre>
</blockquote>
If moving a referencing wc into MD, this could happend automatically
the next time MD detects sub-wc's (during cleanup) and change wc from
referencing to non-referencing.<br>
<blockquote
cite="mid:738d207f0809151456n4ff9d97bw29f293ebe181c308@mail.gmail.com"
type="cite">
<pre wrap="">Other than a lack of means to clean-up, there's no reason we could not
support an argument to specify where the MD is rather than just look
for one in the parent path. That lack of clean-up could suck a bit
though.
</pre>
</blockquote>
If MD have abs path to wc's outside MD, cleanup could be disabled if
not all referenced wc's can be reached (error: cannot cleanup,
referenced wc X not found), and this can be remedied by either removing
the wc reference or update the reference (manually by running a
command). But since the referencing wc have abs path to MD, any
operations done on a referencing wc (after a move\rename), can update
the wc's abs path in MD, so this would (mostly) happend automatically.<br>
<br>
But I'm just dreaming here: this sounds a bit (too) complicated:-)<br>
<br>
Gunnar.<br>
<blockquote
cite="mid:738d207f0809151456n4ff9d97bw29f293ebe181c308@mail.gmail.com"
type="cite">
<pre wrap="">
--
Talden
</pre>
</blockquote>
</body>
</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Talden <ta...@gmail.com>.
> That a wc is fully operational on its own is very important, and I often
> move wc's around and it "just works". This was one of the reasons we moved
> from Vault.
Again, ala Bazaar.
1. Checking out a Working-Copy (WC) without a separate Meta-Data area (MD).
Creates a .svn at the top of the WC that has all of the meta-data
required for the WC to be completely standalone.
2. Checking out a WC into a folder that is enclosed by an MD.
Creates a .svn at the top of the WC that knows to locate and place
certain meta-data further up the path tree (no record of where,
relative or absolute, so that they are independently movable).
- Standalone WCs can be moved around freely.
- WCs inside an MD can be moved around freely within the MD.
- A command is needed to make a WC inside an MD into a standalone that
can be moved outside of the enclosing MD.
- A command is also needed to efficiently move a WC into an enclosing MD.
Other than a lack of means to clean-up, there's no reason we could not
support an argument to specify where the MD is rather than just look
for one in the parent path. That lack of clean-up could suck a bit
though.
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Gunnar Dalsnes <ha...@online.no>.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="mid:20080915124146.GA25152@jack.stsp.name" type="cite">
<pre wrap=""><!---->
We could _always_ have a .svn directory at the WC root, right?
And if this directory does not host the meta data itself, it could
provide a pointer to where it thinks the meta data should be.
Stefan
</pre>
</blockquote>
+1<br>
<br>
That a wc is fully operational on its own is very important, and I
often move wc's around and it "just works". This was one of the reasons
we moved from Vault.<br>
<br>
Me thinks metadata should always reside a sole .svn folder in wc root,
but it could optionally point to a shared location where base files are
chached\shared between multiple wc's from same repo: lightning fast
checkout of new branches:-) If I delete the shared location or move the
wc to a different computer, it should still "just work": shared
location will be rebuilt by automatically fetching files from repo.<br>
<br>
Gunnar.<br>
<blockquote cite="mid:20080915124146.GA25152@jack.stsp.name" type="cite">
<pre wrap="">
---------------------------------------------------------------------
To unsubscribe, e-mail: <a class="moz-txt-link-abbreviated" href="mailto:dev-unsubscribe@subversion.tigris.org">dev-unsubscribe@subversion.tigris.org</a>
For additional commands, e-mail: <a class="moz-txt-link-abbreviated" href="mailto:dev-help@subversion.tigris.org">dev-help@subversion.tigris.org</a>
</pre>
</blockquote>
</body>
</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Sep 15, 2008 at 05:17:25AM -0700, Greg Stein wrote:
> On Mon, Sep 15, 2008 at 5:07 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Greg Stein wrote on Mon, 15 Sep 2008 at 04:29 -0700:
> >> That's a good point. I was thinking that it wouldn't be a big deal...
> >> svn can easily track the references. But I guess not so much if you
> >> just blast the WC out from under it :-P
> >
> > And what if, rather than blasted away, the WC was renamed or duplicated
> > (causing the reference count to be lower than actuality)? How do you
> > fix the reference counts then?
>
> If it is renamed, then you've just "lost" your metadata. The metadata
> is tied to an absolute path.
Couldn't we also track this the other way round?
As in, have the working copy know where the meta data is located?
I guess the next question would be where to put meta data about
meta data :) I'd suggest a mandatory .svn directory at the WC root.
> It seems possible to have some admin command to notify svn that you
> renamed the directory, but I'd rather just say "don't do that, or keep
> the metadata inside the WC if you're gonna move it around." Same thing
> goes for copies.
Please let's not just punt on this. Working copies may get renamed/moved
for any number of reasons, sometimes beyond control of individual developers.
E.g. network shares that are mounted at different paths on different
systems -- I know that is a stupid setup but in reality this kind of
stuff exists in the wild, and it would be probably a PITA for many
people if Subversion wasn't able to work in such environments.
I'd rather assume that working copies get moved around all the time
(in their entirety) than assume that they never will.
> >> Well, the metadata *will* know where all the working copies are.
> >
> > We could have the wc record itself every time some svn command accesses
> > it -- is this what you plan?
>
> I was thinking each time you did a checkout, that it would say "hey!
> new working copy" and record it. There isn't a way to auto-discover a
> working copy when a command is invoked because there is nothing *in*
> the directory to say where it came from, what version is represented,
> etc.
We could _always_ have a .svn directory at the WC root, right?
And if this directory does not host the meta data itself, it could
provide a pointer to where it thinks the meta data should be.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Blair Zajac <bl...@orcaware.com>.
Greg Stein wrote:
> On Mon, Sep 15, 2008 at 5:07 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> Greg Stein wrote on Mon, 15 Sep 2008 at 04:29 -0700:
>>> That's a good point. I was thinking that it wouldn't be a big deal...
>>> svn can easily track the references. But I guess not so much if you
>>> just blast the WC out from under it :-P
>> And what if, rather than blasted away, the WC was renamed or duplicated
>> (causing the reference count to be lower than actuality)? How do you
>> fix the reference counts then?
>
> If it is renamed, then you've just "lost" your metadata. The metadata
> is tied to an absolute path.
>
> It seems possible to have some admin command to notify svn that you
> renamed the directory, but I'd rather just say "don't do that, or keep
> the metadata inside the WC if you're gonna move it around." Same thing
> goes for copies.
I use rsync to duplicate a working copy whenever I need a new working copy
instead of doing a fresh checkout, since it's much faster. So it would be nice
to say, here's a new copied/moved working copy, but maybe the speed of the new
wc code would make rsync duplicates unnecessary.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Sep 15, 2008 at 8:04 AM, Listman <li...@burble.net> wrote:
>...
>> Ah, so the "metadata" completely replaces .svn dirs? I thought just the
>> text-bases would be centralised.
All of it can be centralized, yes. The metadata/bases are stored
together, and they can reside in one of several locations:
1) wc root
2) your home dir
3) arbitrary location
> unfortunately there's a number of non-cooperative tools (most of which we
> seem to use :(
> that just delete the .svn dirs during their operation and break our working
> copies. centralizing
> *ALL* the metadata gets my vote..
Well, we can't say "don't put a .svn at the root because it can get
deleted". By that logic, we'd be broken *today*.
We could drop a .svn directory at the wc root that identifies the wc
for the centralized datastore. That would allow us to move wc's
around. We can also use the absolute path (as long as they don't
rename) and never drop a .svn directory.
>>> It seems possible to have some admin command to notify svn that you
>>> renamed the directory, but I'd rather just say "don't do that, or keep
>>> the metadata inside the WC if you're gonna move it around." Same thing
>>> goes for copies.
>>
>> So if you want to rename a WC, you have to run 'checkout' again? The
>> latter would take too long; it could be faster to edit the metadata
>> manually than to run checkout from scratch :)
As I said, we could have some admin command. I don't like it, but the
crowd is murmuring that it should be present.
> renaming doesn't happen very often, this is a corner case IMHO and shouldn't
> have a big
> say in what we do here.
Agreed, but let's see how that murmuring goes...
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Listman <li...@burble.net>.
On Sep 15, 2008, at 5:32 AM- Sep 15, 2008, Daniel Shahaf wrote:
> Greg Stein wrote on Mon, 15 Sep 2008 at 05:17 -0700:
>> On Mon, Sep 15, 2008 at 5:07 AM, Daniel Shahaf <d.s@daniel.shahaf.name
>> > wrote:
>>> Greg Stein wrote on Mon, 15 Sep 2008 at 04:29 -0700:
>>>> That's a good point. I was thinking that it wouldn't be a big
>>>> deal...
>>>> svn can easily track the references. But I guess not so much if you
>>>> just blast the WC out from under it :-P
>>>
>>> And what if, rather than blasted away, the WC was renamed or
>>> duplicated
>>> (causing the reference count to be lower than actuality)? How do you
>>> fix the reference counts then?
>>
>> If it is renamed, then you've just "lost" your metadata. The metadata
>> is tied to an absolute path.
>>
>
> Ah, so the "metadata" completely replaces .svn dirs? I thought just
> the
> text-bases would be centralised.
>
unfortunately there's a number of non-cooperative tools (most of which
we seem to use :(
that just delete the .svn dirs during their operation and break our
working copies. centralizing
*ALL* the metadata gets my vote..
>> It seems possible to have some admin command to notify svn that you
>> renamed the directory, but I'd rather just say "don't do that, or
>> keep
>> the metadata inside the WC if you're gonna move it around." Same
>> thing
>> goes for copies.
>>
>
> So if you want to rename a WC, you have to run 'checkout' again? The
> latter would take too long; it could be faster to edit the metadata
> manually than to run checkout from scratch :)
renaming doesn't happen very often, this is a corner case IMHO and
shouldn't have a big
say in what we do here.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Greg Stein wrote on Mon, 15 Sep 2008 at 05:17 -0700:
> On Mon, Sep 15, 2008 at 5:07 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Greg Stein wrote on Mon, 15 Sep 2008 at 04:29 -0700:
> >> That's a good point. I was thinking that it wouldn't be a big deal...
> >> svn can easily track the references. But I guess not so much if you
> >> just blast the WC out from under it :-P
> >
> > And what if, rather than blasted away, the WC was renamed or duplicated
> > (causing the reference count to be lower than actuality)? How do you
> > fix the reference counts then?
>
> If it is renamed, then you've just "lost" your metadata. The metadata
> is tied to an absolute path.
>
Ah, so the "metadata" completely replaces .svn dirs? I thought just the
text-bases would be centralised.
> It seems possible to have some admin command to notify svn that you
> renamed the directory, but I'd rather just say "don't do that, or keep
> the metadata inside the WC if you're gonna move it around." Same thing
> goes for copies.
>
So if you want to rename a WC, you have to run 'checkout' again? The
latter would take too long; it could be faster to edit the metadata
manually than to run checkout from scratch :)
> >> Well, the metadata *will* know where all the working copies are.
> >
> > We could have the wc record itself every time some svn command accesses
> > it -- is this what you plan?
>
> I was thinking each time you did a checkout, that it would say "hey!
> new working copy" and record it. There isn't a way to auto-discover a
> working copy when a command is invoked because there is nothing *in*
> the directory to say where it came from, what version is represented,
> etc.
>
As above (re .svn dirs).
> Cheers,
> -g
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Sep 15, 2008 at 5:07 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Greg Stein wrote on Mon, 15 Sep 2008 at 04:29 -0700:
>> That's a good point. I was thinking that it wouldn't be a big deal...
>> svn can easily track the references. But I guess not so much if you
>> just blast the WC out from under it :-P
>
> And what if, rather than blasted away, the WC was renamed or duplicated
> (causing the reference count to be lower than actuality)? How do you
> fix the reference counts then?
If it is renamed, then you've just "lost" your metadata. The metadata
is tied to an absolute path.
It seems possible to have some admin command to notify svn that you
renamed the directory, but I'd rather just say "don't do that, or keep
the metadata inside the WC if you're gonna move it around." Same thing
goes for copies.
>> Well, the metadata *will* know where all the working copies are.
>
> We could have the wc record itself every time some svn command accesses
> it -- is this what you plan?
I was thinking each time you did a checkout, that it would say "hey!
new working copy" and record it. There isn't a way to auto-discover a
working copy when a command is invoked because there is nothing *in*
the directory to say where it came from, what version is represented,
etc.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Greg Stein wrote on Mon, 15 Sep 2008 at 04:29 -0700:
> That's a good point. I was thinking that it wouldn't be a big deal...
> svn can easily track the references. But I guess not so much if you
> just blast the WC out from under it :-P
>
And what if, rather than blasted away, the WC was renamed or duplicated
(causing the reference count to be lower than actuality)? How do you
fix the reference counts then?
> Well, the metadata *will* know where all the working copies are.
We could have the wc record itself every time some svn command accesses
it -- is this what you plan?
Daniel
> So it would seem that "svn cleanup" can do a verification pass and
> re-tally the reference counts (and do garbage collection), ensure the
> metadata about the working copies is still proper, etc.
>
> I'll add a note about it. Thanks!
>
> Cheers,
> -g
>
> On Mon, Sep 15, 2008 at 3:36 AM, Mattias Engdegård <ma...@virtutech.se> wrote:
> > "Greg Stein" <gs...@gmail.com> writes:
> >
> >>Note that if people keep the /bases/ directory in their home dir, then
> >>the bases will be shared across ALL working copies.
> >
> > I may have overlooked something obvious, but how would garbage
> > collection in a shared text-base tree work? Attempting to keep track
> > of all WCs using it is probably fragile, so I suppose the shared
> > /bases/ would just keep growing - or is there an aging mechanism that
> > throws out base files that haven't been used for a while when the tree
> > reaches a certain size? The client must then be prepared to re-create
> > any base file that turns out to be missing. (Annoying, if working
> > off-line.)
> >
> > With non-shared bases trees (one per WC), a single rm -rf will remove
> > the whole WC and nothing but the WC.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org
> >
> >
Re: Base text files, re: IRC chat
Posted by Greg Stein <gs...@gmail.com>.
That's a good point. I was thinking that it wouldn't be a big deal...
svn can easily track the references. But I guess not so much if you
just blast the WC out from under it :-P
Well, the metadata *will* know where all the working copies are. So it
would seem that "svn cleanup" can do a verification pass and re-tally
the reference counts (and do garbage collection), ensure the metadata
about the working copies is still proper, etc.
I'll add a note about it. Thanks!
Cheers,
-g
On Mon, Sep 15, 2008 at 3:36 AM, Mattias Engdegård <ma...@virtutech.se> wrote:
> "Greg Stein" <gs...@gmail.com> writes:
>
>>Note that if people keep the /bases/ directory in their home dir, then
>>the bases will be shared across ALL working copies.
>
> I may have overlooked something obvious, but how would garbage
> collection in a shared text-base tree work? Attempting to keep track
> of all WCs using it is probably fragile, so I suppose the shared
> /bases/ would just keep growing - or is there an aging mechanism that
> throws out base files that haven't been used for a while when the tree
> reaches a certain size? The client must then be prepared to re-create
> any base file that turns out to be missing. (Annoying, if working
> off-line.)
>
> With non-shared bases trees (one per WC), a single rm -rf will remove
> the whole WC and nothing but the WC.
>
>
> ---------------------------------------------------------------------
> 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: Base text files, re: IRC chat
Posted by Mattias Engdegård <ma...@virtutech.se>.
"Greg Stein" <gs...@gmail.com> writes:
>Note that if people keep the /bases/ directory in their home dir, then
>the bases will be shared across ALL working copies.
I may have overlooked something obvious, but how would garbage
collection in a shared text-base tree work? Attempting to keep track
of all WCs using it is probably fragile, so I suppose the shared
/bases/ would just keep growing - or is there an aging mechanism that
throws out base files that haven't been used for a while when the tree
reaches a certain size? The client must then be prepared to re-create
any base file that turns out to be missing. (Annoying, if working
off-line.)
With non-shared bases trees (one per WC), a single rm -rf will remove
the whole WC and nothing but the WC.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Mon, Sep 15, 2008 at 2:56 PM, Stefan Sperling <st...@elego.de> wrote:
> I'd consider sharing a single working copy between multiple users
> a somewhat exotic use case. At least more exotic than the use case
> of every user owning their own working copies -- in which case
> (2) is clearly the better option.
I don't view having a shared WC as very exotic. I know lots of people
who do that. It "just" works and I'd hate to see that functionality
lost. If you do some manual config options tweaking to break it, I
guess. But, IMO, we should still work with shared WCs out of the box.
-- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Base text files, re: IRC chat
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
I wrote:
> > Wouldn't setting --config-dir (via env var?) to a path sibling to
> > the working copies achieve that effect as well?
>
Summarising IRC for the list: you were talking about the default
behaviour, so my point doesn't apply. Sorry for the confusion.
Daniel
> I see no problem in the user taking the initiative in moving the metadata
> store. But why would we as library developers take the initiative to move it
> to another location, of which can't say it is any better than the original
> location?
>
> Bert
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Base text files, re: IRC chat
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: dinsdag 16 september 2008 19:39
> To: dev@subversion.tigris.org
> Subject: Re: Base text files, re: IRC chat
>
> On Tue, Sep 16, 2008 at 7:17 AM, Bert Huijben <be...@qqmail.nl> wrote:
> >...
> > It's just that none of these users use the CLI as primary client and
> getting
> > all GUIs to pass the same config directory setting is not very
> likely. If
> > they use --config dir they pass their own folder and not one shared
> with all
> > other clients.
>
> Interesting point. People using multiple, variant clients should be
> careful to put their options into the same config directory,
> preferably the default home location (rather than something a client
> has set up).
>
> >...
> > By the way, doesn't your recommendation break our c library API
> contract?
>
> No. The API is the contract, and will remain compatible per the
> guidelines.
The ABI will compatible, but the manuals of the existing applications would
need an update.
> > Someone linking to the 1.4/1.5 library doesn't expect us to store
> Gigabytes
> > of data in their roaming profile when they only access a working copy
> on a
> > network share.
>
> That is not part of the API contract.
>
> Regardless, I think for the element of "least surprise", we are going
> to need to use the "wc root" storage location as the default. I was
> hoping to make the home dir the default, but after this discussion it
> seems there are too many "gotchas" with managing your working copies
> that way. I don't think we'll be able to *quite* make it invisible
> enough in the presence of different use cases out in the wild.
>
> So. Initial release will use "wc root" as the default. We may decide
> to change that in the future, if we can automate enough of the
> repair/detection/etc of WCs.
+1 on using the WC root (or a directory above that via the bazaar like
algorithm suggested by Gunnar) as /default/.
And +1 on allowing the user to choose any other location he likes at his/her
initiative. (Preferably locatable via some reference in the working copy to
allow multiple config directories)
If you find a stable algorithm to always choose 'the right location' on all
Oss, I think I use it in our TCG applications ;-)
I'm just afraid I find another sysadmin that configures that right location
to a limited network resource after all.. :(
Bert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Sep 16, 2008 at 10:39:10AM -0700, Greg Stein wrote:
> So. Initial release will use "wc root" as the default. We may decide
> to change that in the future, if we can automate enough of the
> repair/detection/etc of WCs.
+1
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Sep 16, 2008 at 7:17 AM, Bert Huijben <be...@qqmail.nl> wrote:
>...
> It's just that none of these users use the CLI as primary client and getting
> all GUIs to pass the same config directory setting is not very likely. If
> they use --config dir they pass their own folder and not one shared with all
> other clients.
Interesting point. People using multiple, variant clients should be
careful to put their options into the same config directory,
preferably the default home location (rather than something a client
has set up).
>...
> By the way, doesn't your recommendation break our c library API contract?
No. The API is the contract, and will remain compatible per the guidelines.
> Someone linking to the 1.4/1.5 library doesn't expect us to store Gigabytes
> of data in their roaming profile when they only access a working copy on a
> network share.
That is not part of the API contract.
Regardless, I think for the element of "least surprise", we are going
to need to use the "wc root" storage location as the default. I was
hoping to make the home dir the default, but after this discussion it
seems there are too many "gotchas" with managing your working copies
that way. I don't think we'll be able to *quite* make it invisible
enough in the presence of different use cases out in the wild.
So. Initial release will use "wc root" as the default. We may decide
to change that in the future, if we can automate enough of the
repair/detection/etc of WCs.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Base text files, re: IRC chat
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> Sent: dinsdag 16 september 2008 15:50
> To: Stefan Sperling
> Cc: dev@subversion.tigris.org
> Subject: Re: Base text files, re: IRC chat
>
> Stefan Sperling wrote on Tue, 16 Sep 2008 at 15:27 +0200:
> > On Tue, Sep 16, 2008 at 12:35:17AM +0200, Bert Huijben wrote:
> > > I really wouldn't recommend using (2) as the Windows default. In
> many
> > > corporate environments ~/ is in the roaming user profile.
> (Automatically
> > > locally cached and sometimes automatically merged when a user logs
> on onto
> > > different machines at the same time). And in most of these cases
> the size of
> > > the roaming profiles is pretty limited (100 MB max at one of our
> largest
> > > customers)
> >
> > This is a good point.
> >
> > Do we want defaults to differ between platforms?
>
> Not unless we have to. And I'm not sure we want them to differ here.
>
> > Because on *nix, with the concept of $HOME, (2) makes a lot of sense.
>
> Well, Windows also has that concept, %USERPROFILE%. And having quotas
> on it isn't a limitation unique to Windows :)
>
> In Bert's case, these people have working copies somewhere, and what we
> want is to store the metadata there rather than at the %USERPROFILE%,
> right? Wouldn't setting --config-dir (via env var?) to a path sibling
> to
> the working copies achieve that effect as well?
It's just that none of these users use the CLI as primary client and getting
all GUIs to pass the same config directory setting is not very likely. If
they use --config dir they pass their own folder and not one shared with all
other clients.
Asking from all users to explicitly set or pass a storage location only
proves the point that we can't provide a new/better sensible default for a
central metadata store.
By the way, doesn't your recommendation break our c library API contract?
Someone linking to the 1.4/1.5 library doesn't expect us to store Gigabytes
of data in their roaming profile when they only access a working copy on a
network share.
I see no problem in the user taking the initiative in moving the metadata
store. But why would we as library developers take the initiative to move it
to another location, of which can't say it is any better than the original
location?
Bert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Barry Scott wrote on Sat, 20 Sep 2008 at 10:50 +0100:
> On Sep 16, 2008, at 14:50, Daniel Shahaf wrote:
> > Stefan Sperling wrote on Tue, 16 Sep 2008 at 15:27 +0200:
> > > Because on *nix, with the concept of $HOME, (2) makes a lot of sense.
> >
> > Well, Windows also has that concept, %USERPROFILE%. And having quotas
> > on it isn't a limitation unique to Windows :)
> >
>
> Surely its %APPDATA%\Subversion you would use as the default on Windows?
>
The sentence you quote doesn't say anything to contradict that. To
answer your question, the default will be the wc root -- see the rest of
the thread.
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Barry Scott <ba...@barrys-emacs.org>.
On Sep 16, 2008, at 14:50, Daniel Shahaf wrote:
> Stefan Sperling wrote on Tue, 16 Sep 2008 at 15:27 +0200:
>> On Tue, Sep 16, 2008 at 12:35:17AM +0200, Bert Huijben wrote:
>>> I really wouldn't recommend using (2) as the Windows default. In
>>> many
>>> corporate environments ~/ is in the roaming user profile.
>>> (Automatically
>>> locally cached and sometimes automatically merged when a user
>>> logs on onto
>>> different machines at the same time). And in most of these cases
>>> the size of
>>> the roaming profiles is pretty limited (100 MB max at one of our
>>> largest
>>> customers)
>>
>> This is a good point.
>>
>> Do we want defaults to differ between platforms?
>
> Not unless we have to. And I'm not sure we want them to differ here.
>
>> Because on *nix, with the concept of $HOME, (2) makes a lot of sense.
>
> Well, Windows also has that concept, %USERPROFILE%. And having quotas
> on it isn't a limitation unique to Windows :)
>
Surely its %APPDATA%\Subversion you would use as the default on Windows?
> In Bert's case, these people have working copies somewhere, and
> what we
> want is to store the metadata there rather than at the %USERPROFILE%,
> right? Wouldn't setting --config-dir (via env var?) to a path
> sibling to
> the working copies achieve that effect as well?
>
> Daniel
>
> (do we already allow setting --config-dir by an env var?)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Tue, 16 Sep 2008 at 15:27 +0200:
> On Tue, Sep 16, 2008 at 12:35:17AM +0200, Bert Huijben wrote:
> > I really wouldn't recommend using (2) as the Windows default. In many
> > corporate environments ~/ is in the roaming user profile. (Automatically
> > locally cached and sometimes automatically merged when a user logs on onto
> > different machines at the same time). And in most of these cases the size of
> > the roaming profiles is pretty limited (100 MB max at one of our largest
> > customers)
>
> This is a good point.
>
> Do we want defaults to differ between platforms?
Not unless we have to. And I'm not sure we want them to differ here.
> Because on *nix, with the concept of $HOME, (2) makes a lot of sense.
Well, Windows also has that concept, %USERPROFILE%. And having quotas
on it isn't a limitation unique to Windows :)
In Bert's case, these people have working copies somewhere, and what we
want is to store the metadata there rather than at the %USERPROFILE%,
right? Wouldn't setting --config-dir (via env var?) to a path sibling to
the working copies achieve that effect as well?
Daniel
(do we already allow setting --config-dir by an env var?)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Sep 16, 2008 at 12:35:17AM +0200, Bert Huijben wrote:
> > > At 8:48 PM -0700 9/14/08, Greg Stein wrote:
> > >> There are basically three options:
> > >>
> > >> 1) at the root of the working copy, in a .svn subdirectory
> > >> 2) in a subdir of ~/.subversion/
> > >> 3) in a directory specified by your config (and/or an environ
> > variable?)
> > >>
> I would prefer (1) to be the default as it is the closest match to the old
> behavior: the user chooses where the data is stored.
I think you mean:
The user choses where the working copy is placed, and with
(1), this implies where meta data is stored.
Because the user will always be able to choose where meta data
is stored, regardless of the default behaviour.
> I really wouldn't recommend using (2) as the Windows default. In many
> corporate environments ~/ is in the roaming user profile. (Automatically
> locally cached and sometimes automatically merged when a user logs on onto
> different machines at the same time). And in most of these cases the size of
> the roaming profiles is pretty limited (100 MB max at one of our largest
> customers)
This is a good point.
Do we want defaults to differ between platforms?
Because on *nix, with the concept of $HOME, (2) makes a lot of sense.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Base text files, re: IRC chat
Posted by Bert Huijben <be...@vmoo.com>.
> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@elego.de]
> Sent: maandag 15 september 2008 23:57
> To: Garance A Drosihn
> Cc: Greg Stein; Talden; dev@subversion.tigris.org
> Subject: Re: Base text files, re: IRC chat
>
> On Mon, Sep 15, 2008 at 05:20:31PM -0400, Garance A Drosihn wrote:
> > At 8:48 PM -0700 9/14/08, Greg Stein wrote:
> >> There are basically three options:
> >>
> >> 1) at the root of the working copy, in a .svn subdirectory
> >> 2) in a subdir of ~/.subversion/
> >> 3) in a directory specified by your config (and/or an environ
> variable?)
> >>
> >> I'm leaning more and more towards making option (2) be the default
> >> because of the advantages of sharing text bases. At first, I was
> >> thinking (1) would be the default.
> >
> > I'd think that (1) would be the better default. What happens if
> > multiple people might be using a single working copy?
>
> You could configure subversion to always do (1) in your system-wide
> (or per-user) Subversion configuration files. I presume we will be
> adding both command line switches and configuratoin file options
> to control this behaviour.
I would prefer (1) to be the default as it is the closest match to the old
behavior: the user chooses where the data is stored.
It provides most of the performance benefits of the new store without
changing how to use subversion.
I really wouldn't recommend using (2) as the Windows default. In many
corporate environments ~/ is in the roaming user profile. (Automatically
locally cached and sometimes automatically merged when a user logs on onto
different machines at the same time). And in most of these cases the size of
the roaming profiles is pretty limited (100 MB max at one of our largest
customers)
I can certainly think of scenario's where I would prefer (2) as option, but
I don't know a default windows location where non-admin users can always
write a lot of data. (I found %TEMP% in the per-user roaming profile at
another customer).
The:
# svn co http://example.com/path /wc/myproject/kiwi --metadata=c:/metastore
Example in one of the mails from Greg, looks pretty clean to me; allowing me
to optimize working copy at creation. And I think it is one of the few
variants that would be easy to implement in an existing GUI.
+1 on storing the reference in .svn/ below the working copy root.
Many of our AnkhSVN users use working copies on remote machines for websites
(sometimes shared). Defaulting to a local metastore would enhance their
performance by an order of magnitude, but would break using the same working
copy from different machines via different UNC paths.
I think we would have a lot of explaining to do, if we would break multiple
network paths to the same location in the default configuration.
Bert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Steven Bakke <st...@amd.com>.
+1 to supporting working copies with multiple users. It's not my
preferred mode of operation, but due to reasons outside my control, we
rely on this ability and removing it would cause problems.
-Steve
On Sep 15, 2008, at 6:56 PM, Greg Stein wrote:
> I was hoping to drop that "feature" :-)
>
> It shouldn't be hard to maintain, though, since sqlite handles most
> of it. I'll only need to be careful around writing a new base into
> the datastore.
>
> Cheers,
> -g
>
>
> On Sep 15, 2008, at 18:43, Garance A Drosihn <dr...@rpi.edu> wrote:
>
>> At 11:56 PM +0200 9/15/08, Stefan Sperling wrote:
>>> On Mon, Sep 15, 2008 at 05:20:31PM -0400, Garance A Drosihn wrote:
>>>> At 8:48 PM -0700 9/14/08, Greg Stein wrote:
>>>>> There are basically three options:
>>>>>
>>>>> 1) at the root of the working copy, in a .svn subdirectory
>>>>> 2) in a subdir of ~/.subversion/
>>>>> 3) in a directory specified by your config (and/or an environ
>>>>> variable?)
>>>>>
>>>>> I'm leaning more and more towards making option (2) be the default
>>>>> because of the advantages of sharing text bases. At first, I was
>>>>> thinking (1) would be the default.
>>>>
>>>> I'd think that (1) would be the better default. What happens if
>>> > multiple people might be using a single working copy?
>>
>>
>>> I'd consider sharing a single working copy between multiple users
>>> a somewhat exotic use case. At least more exotic than the use case
>>> of every user owning their own working copies -- in which case
>>> (2) is clearly the better option.
>>
>> Hmm. It also occurs to me that the one of the side-effects of
>> how we work is that we aren't often checking out new working
>> copies. I guess this isn't as big of an issue as I first thought
>> it might be. Let me just ask that the new code will still support
>> WC's which are used among multiple people (for those who need to
>> work that way), but I agree that that ability need not influence
>> the default behavior of svn.
>>
>> --
>> Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
>> Senior Systems Programmer or gad@freebsd.org
>> Rensselaer Polytechnic Institute or drosih@rpi.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Greg Stein <gs...@gmail.com>.
I was hoping to drop that "feature" :-)
It shouldn't be hard to maintain, though, since sqlite handles most of
it. I'll only need to be careful around writing a new base into the
datastore.
Cheers,
-g
On Sep 15, 2008, at 18:43, Garance A Drosihn <dr...@rpi.edu> wrote:
> At 11:56 PM +0200 9/15/08, Stefan Sperling wrote:
>> On Mon, Sep 15, 2008 at 05:20:31PM -0400, Garance A Drosihn wrote:
>>> At 8:48 PM -0700 9/14/08, Greg Stein wrote:
>>>> There are basically three options:
>>>>
>>>> 1) at the root of the working copy, in a .svn subdirectory
>>>> 2) in a subdir of ~/.subversion/
>>>> 3) in a directory specified by your config (and/or an environ
>>>> variable?)
>>>>
>>>> I'm leaning more and more towards making option (2) be the default
>>>> because of the advantages of sharing text bases. At first, I was
>>>> thinking (1) would be the default.
>>>
>>> I'd think that (1) would be the better default. What happens if
>> > multiple people might be using a single working copy?
>
>
>> I'd consider sharing a single working copy between multiple users
>> a somewhat exotic use case. At least more exotic than the use case
>> of every user owning their own working copies -- in which case
>> (2) is clearly the better option.
>
> Hmm. It also occurs to me that the one of the side-effects of
> how we work is that we aren't often checking out new working
> copies. I guess this isn't as big of an issue as I first thought
> it might be. Let me just ask that the new code will still support
> WC's which are used among multiple people (for those who need to
> work that way), but I agree that that ability need not influence
> the default behavior of svn.
>
> --
> Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
> Senior Systems Programmer or gad@freebsd.org
> Rensselaer Polytechnic Institute or drosih@rpi.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Garance A Drosihn <dr...@rpi.edu>.
At 11:56 PM +0200 9/15/08, Stefan Sperling wrote:
>On Mon, Sep 15, 2008 at 05:20:31PM -0400, Garance A Drosihn wrote:
>> At 8:48 PM -0700 9/14/08, Greg Stein wrote:
>>> There are basically three options:
>>>
>>> 1) at the root of the working copy, in a .svn subdirectory
>>> 2) in a subdir of ~/.subversion/
>>> 3) in a directory specified by your config (and/or an environ variable?)
>>>
>>> I'm leaning more and more towards making option (2) be the default
>>> because of the advantages of sharing text bases. At first, I was
>>> thinking (1) would be the default.
>>
>> I'd think that (1) would be the better default. What happens if
> > multiple people might be using a single working copy?
>I'd consider sharing a single working copy between multiple users
>a somewhat exotic use case. At least more exotic than the use case
>of every user owning their own working copies -- in which case
>(2) is clearly the better option.
Hmm. It also occurs to me that the one of the side-effects of
how we work is that we aren't often checking out new working
copies. I guess this isn't as big of an issue as I first thought
it might be. Let me just ask that the new code will still support
WC's which are used among multiple people (for those who need to
work that way), but I agree that that ability need not influence
the default behavior of svn.
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Sep 15, 2008 at 05:20:31PM -0400, Garance A Drosihn wrote:
> At 8:48 PM -0700 9/14/08, Greg Stein wrote:
>> There are basically three options:
>>
>> 1) at the root of the working copy, in a .svn subdirectory
>> 2) in a subdir of ~/.subversion/
>> 3) in a directory specified by your config (and/or an environ variable?)
>>
>> I'm leaning more and more towards making option (2) be the default
>> because of the advantages of sharing text bases. At first, I was
>> thinking (1) would be the default.
>
> I'd think that (1) would be the better default. What happens if
> multiple people might be using a single working copy?
You could configure subversion to always do (1) in your system-wide
(or per-user) Subversion configuration files. I presume we will be
adding both command line switches and configuratoin file options
to control this behaviour.
> That's how
> we work here at RPI, and that's a sensible way for us to work (not
> that I want to explain why it's sensible for us).
I think (2) is a better default because it would give most users
a huge speed advantage without having to configure anything.
The defaults should be chosen so that a minumum amount of people
have to tweak a minimum amount of knobs to get Subversion to
do what they want it to do.
I'd consider sharing a single working copy between multiple users
a somewhat exotic use case. At least more exotic than the use case
of every user owning their own working copies -- in which case
(2) is clearly the better option.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Garance A Drosihn <dr...@rpi.edu>.
At 8:48 PM -0700 9/14/08, Greg Stein wrote:
>On Sun, Sep 14, 2008 at 8:06 PM, Talden <ta...@gmail.com> wrote:
>>...
>>> Note that if people keep the /bases/ directory in their home dir...
>>
>> As long as there's the ability to redirect this (via a small file in
>> home. EG config) to somewhere away from home which is not always the
>> fastest or largest disk.
>
>You bet. At my last job, our home directories were on NFS, so I'm
>*very* aware of not wanting to put the bases and metadata there :-)
>
>There are basically three options:
>
>1) at the root of the working copy, in a .svn subdirectory
>2) in a subdir of ~/.subversion/
>3) in a directory specified by your config (and/or an environ variable?)
>
>I'm leaning more and more towards making option (2) be the default
>because of the advantages of sharing text bases. At first, I was
>thinking (1) would be the default.
I'd think that (1) would be the better default. What happens if
multiple people might be using a single working copy? That's how
we work here at RPI, and that's a sensible way for us to work (not
that I want to explain why it's sensible for us).
disclaimer: I'm not sure I completely understand what your plan is,
so maybe the problem here is in my own head.
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Listman <li...@burble.net>.
On Sep 14, 2008, at 8:48 PM- Sep 14, 2008, Greg Stein wrote:
> On Sun, Sep 14, 2008 at 8:06 PM, Talden <ta...@gmail.com> wrote:
>> ...
>>> Note that if people keep the /bases/ directory in their home dir...
>>
>> As long as there's the ability to redirect this (via a small file in
>> home. EG config) to somewhere away from home which is not always the
>> fastest or largest disk.
>
> You bet. At my last job, our home directories were on NFS, so I'm
> *very* aware of not wanting to put the bases and metadata there :-)
>
> There are basically three options:
>
> 1) at the root of the working copy, in a .svn subdirectory
> 2) in a subdir of ~/.subversion/
> 3) in a directory specified by your config (and/or an environ
> variable?)
>
> I'm leaning more and more towards making option (2) be the default
> because of the advantages of sharing text bases. At first, I was
> thinking (1) would be the default.
>
i'm getting the warm-fuzzies :)
your tab at the Toronado awaits you Greg!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Greg Stein <gs...@gmail.com>.
On Sun, Sep 14, 2008 at 8:06 PM, Talden <ta...@gmail.com> wrote:
>...
>> Note that if people keep the /bases/ directory in their home dir...
>
> As long as there's the ability to redirect this (via a small file in
> home. EG config) to somewhere away from home which is not always the
> fastest or largest disk.
You bet. At my last job, our home directories were on NFS, so I'm
*very* aware of not wanting to put the bases and metadata there :-)
There are basically three options:
1) at the root of the working copy, in a .svn subdirectory
2) in a subdir of ~/.subversion/
3) in a directory specified by your config (and/or an environ variable?)
I'm leaning more and more towards making option (2) be the default
because of the advantages of sharing text bases. At first, I was
thinking (1) would be the default.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Base text files, re: IRC chat
Posted by Talden <ta...@gmail.com>.
> Well, my current plan is...
Generally, I like this plan. 8-)
> Note that if people keep the /bases/ directory in their home dir...
As long as there's the ability to redirect this (via a small file in
home. EG config) to somewhere away from home which is not always the
fastest or largest disk.
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org