You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Hyrum K. Wright" <hy...@mail.utexas.edu> on 2009/03/02 18:49:58 UTC
Subversion 1.6.0 Release Candidate 3 Released
On the road to 1.6.0, I'm happy to announce Subversion 1.6.0-rc3,
available from:
http://subversion.tigris.org/downloads/subversion-1.6.0-rc3.tar.bz2
http://subversion.tigris.org/downloads/subversion-1.6.0-rc3.tar.gz
http://subversion.tigris.org/downloads/subversion-1.6.0-rc3.zip
http://subversion.tigris.org/downloads/subversion-deps-1.6.0-rc3.tar.bz2
http://subversion.tigris.org/downloads/subversion-deps-1.6.0-rc3.tar.gz
http://subversion.tigris.org/downloads/subversion-deps-1.6.0-
rc3.zip
The MD5 checksums are:
58473cb07611fd7567b6ce99461009e1 subversion-1.6.0-rc3.tar.bz2
77c2d0d6ac9951828622d1a42688ff7a subversion-1.6.0-rc3.tar.gz
02efd53bfaf8ce5287811fa57bfd1246 subversion-1.6.0-rc3.zip
63ff48e0ef13031982e4c70886779f30 subversion-deps-1.6.0-rc3.tar.bz2
c02e27ff97fd4dc213d32fe534a5d215 subversion-deps-1.6.0-rc3.tar.gz
f159325b66a9ee6a6635c29bf47ff683 subversion-deps-1.6.0-rc3.zip
The SHA1 checksums are:
66151726c36474ffacd13be19d7a56c996d1bd75 subversion-1.6.0-
rc3.tar.bz2
ea0d7cb790110c1ef4c220396b1be1999048a527 subversion-1.6.0-
rc3.tar.gz
9ba78f920688a1657647f2ba41c50bd766bca25e subversion-1.6.0-rc3.zip
8561ea3dbbaab0fc590d8a6169d3f37a7759979c subversion-deps-1.6.0-
rc3.tar.bz2
c8b5a64372ba2877b3e587a8112beb00c31b3ca5 subversion-deps-1.6.0-
rc3.tar.gz
23e60bef2b26c3f1989f8241aa287d2b61c38f74 subversion-deps-1.6.0-
rc3.zip
PGP Signatures are available at:
http://subversion.tigris.org/downloads/subversion-1.6.0-rc3.tar.bz2.asc
http://subversion.tigris.org/downloads/subversion-1.6.0-rc3.tar.gz.asc
http://subversion.tigris.org/downloads/subversion-1.6.0-rc3.zip.asc
http://subversion.tigris.org/downloads/subversion-deps-1.6.0-rc3.tar.bz2.asc
http://subversion.tigris.org/downloads/subversion-deps-1.6.0-rc3.tar.gz.asc
http://subversion.tigris.org/downloads/subversion-deps-1.6.0-rc3.zip.asc
For this release, the following people have provided PGP signatures:
Senthil Kumaran S [1024D/6CCD4038] with fingerprint:
8035 16A5 1D6E 50E2 1ECD DE56 F68D 46FB 6CCD 4038
C. Michael Pilato [1024D/1706FD6E] with fingerprint:
20BF 14DC F02F 2730 7EA4 C7BB A241 06A9 1706 FD6E
Paul T. Burba [1024D/53FCDC55] with fingerprint:
E630 CF54 792C F913 B13C 32C5 D916 8930 53FC DC55
Bert Huijben [1024D/9821F7B2] with fingerprint:
2017 F51A 2572 0E78 8827 5329 FCFD 6305 9821 F7B2
Hyrum K. Wright [1024D/4E24517C] with fingerprint:
3324 80DA 0F8C A37D AEE6 D084 0B03 AE6E 4E24 517C
Stefan Sperling [1024D/F59D25F0] with fingerprint:
B1CF 1060 A1E9 34D1 9E86 D6D6 E5D3 0273 F59D 25F0
Mark Phippard [1024D/035A96A9] with fingerprint:
D315 89DB E1C1 E9BA D218 39FD 265D F8A0 035A 96A9
The term 'release candidate' means the Subversion developers feel that
this
release is stable and ready to be tested in production use. If this
testing
confirms its readiness, this candidate version will become the final
released
version. Therefore, we encourage people to test this release
thoroughly.
As a note to operating system distro packagers: while we wish to have
this
release candidate widely tested, we do not feel that it is ready for
packaging
and providing to end-users through a distro package system. Packaging a
release candidate poses many problems, the biggest being that our
policy lets
us break compatibility between the release candidate and the final
release, if
we find something serious enough. Having many users depending on a
release
candidate through their distro would cause no end of pain and
frustration that
we do not want to have to deal with. However, if your distro has a
branch that
is clearly labeled as containing experimental and often broken
software, and
explicitly destined to consenting developers and integrators only,
then we're
okay with packaging the release candidate there. Just don't let it
near the
end users please.
Release notes for the 1.6.x release series may be found at:
http://subversion.tigris.org/svn_1.6_releasenotes.html
You can find the list of changes between 1.6.0-rc3 and earlier
versions at:
http://svn.collab.net/repos/svn/tags/1.6.0-rc3/CHANGES
Questions, comments, and bug reports to users@subversion.tigris.org.
Thanks,
- The Subversion Team
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1257675
Re: Subversion 1.6.0 Release Candidate 3 Released
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Mar 4, 2009 at 12:04 PM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
>
> On Mar 4, 2009, at 10:54 AM, Mark Phippard wrote:
>
>> On Wed, Mar 4, 2009 at 11:36 AM, Hyrum K. Wright
>> <hy...@mail.utexas.edu> wrote:
>>
>>> There are various thoughts and proposals floating around regarding
>>> this. I'd personally like to see Subversion tie into the FSEvents API
>>> on OS X and get filesystem change information directly from the
>>> operating system. Unfortunately, Windows doesn't provide such a
>>> service yet. :/
>>
>> Of course it does. How do you think the TortoiseSVN cache works?
>
> Granted, I'm not very familiar with Windows development and APIs, but when I
> was looking at this for OS X, Linux, and Windows, most resources I found
> said there wasn't an equivalent facility on Windows. Quoting Todd earlier
> in the thread:
I mainly wanted to bust your chops. But my recollection of TSVNCache
is that it receives notification of FS events and uses those as a
trigger to maintain the cache.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1267718
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Subversion 1.6.0 Release Candidate 3 Released
Posted by Bob Archer <bo...@amsi.com>.
> Re: FSEvents, it's tough for me to read
>
http://developer.apple.com/DOCUMENTATION/DARWIN/Reference/FSEvents_Ref/F
> SEvents/index.html but it does seem as though you're correct about
being
> able to come back later since the change events are stored
persistently.
> (Based on my reading, I politely if a little naively disagree with Bob
> Archer's subsequent response on this thread.)
I was never commenting on the OS x stuff... just windows.
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1267939
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Subversion 1.6.0 Release Candidate 3 Released
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Mar 4, 2009, at 12:07 PM, Gleason, Todd wrote:
>> Do you have to be running a process to use these? The nice thing
>> about FSEvents is that (IIUC) you can just subscribe the the
>> directory, quit your process, and then comeback later and ask it what
>> changed. It might take some selling to convince the devs and the
>> users that a daemon is needed for Subversion.
>>
>> -Hyrum
>
> Yes, as far as I can tell you must run a process.
>
> The need to have a daemon (or service, to use Windows terminology) is
> exactly why I suggested that this be optional. I expect most users
> would want it installed for the better performance, but some might
> not,
> or might want to toggle it on and off.
>
> Re: FSEvents, it's tough for me to read
> http://developer.apple.com/DOCUMENTATION/DARWIN/Reference/FSEvents_Ref/F
> SEvents/index.html but it does seem as though you're correct about
> being
> able to come back later since the change events are stored
> persistently.
> (Based on my reading, I politely if a little naively disagree with Bob
> Archer's subsequent response on this thread.)
>
> But personally, I'd be worried if this went on too long (say the user
> adds, rewrites, and deletes files like crazy without touching svn--
> does
> the persistent change information fill the filesystem?). I would
> rather
> have a daemon consuming the FSEvents data whenever possible, or not
> use
> it at all.
>
> One other thing: The wiki at http://en.wikipedia.org/wiki/FSEvents
> compared FSEvents to the Linux inotify at
> http://en.wikipedia.org/wiki/Inotify. From what I can tell, inotify
> operates more similarly to how Windows does--no persistence that I can
> see.
>
> No idea about other OS's, but since this functionality isn't something
> you can count on everywhere, obviously svn must work without it.
> However, with it, a lot of client operations could see tremendous
> performance boosts. I even saw a link
> (http://markmail.org/message/vmigwu3wfxsy7r7z) where they talked about
> FSEvents for Mercurial, so I'm glad to hear that the svn developers
> are
> considering this capability.
Well, in this case "the svn developers" = "me", so don't hold your
breath for this anytime soon. :)
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1267902
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Subversion 1.6.0 Release Candidate 3 Released
Posted by "Todd C. Gleason" <tg...@impac.com>.
> Do you have to be running a process to use these? The nice thing
> about FSEvents is that (IIUC) you can just subscribe the the
> directory, quit your process, and then comeback later and ask it what
> changed. It might take some selling to convince the devs and the
> users that a daemon is needed for Subversion.
>
> -Hyrum
Yes, as far as I can tell you must run a process.
The need to have a daemon (or service, to use Windows terminology) is
exactly why I suggested that this be optional. I expect most users
would want it installed for the better performance, but some might not,
or might want to toggle it on and off.
Re: FSEvents, it's tough for me to read
http://developer.apple.com/DOCUMENTATION/DARWIN/Reference/FSEvents_Ref/F
SEvents/index.html but it does seem as though you're correct about being
able to come back later since the change events are stored persistently.
(Based on my reading, I politely if a little naively disagree with Bob
Archer's subsequent response on this thread.)
But personally, I'd be worried if this went on too long (say the user
adds, rewrites, and deletes files like crazy without touching svn--does
the persistent change information fill the filesystem?). I would rather
have a daemon consuming the FSEvents data whenever possible, or not use
it at all.
One other thing: The wiki at http://en.wikipedia.org/wiki/FSEvents
compared FSEvents to the Linux inotify at
http://en.wikipedia.org/wiki/Inotify. From what I can tell, inotify
operates more similarly to how Windows does--no persistence that I can
see.
No idea about other OS's, but since this functionality isn't something
you can count on everywhere, obviously svn must work without it.
However, with it, a lot of client operations could see tremendous
performance boosts. I even saw a link
(http://markmail.org/message/vmigwu3wfxsy7r7z) where they talked about
FSEvents for Mercurial, so I'm glad to hear that the svn developers are
considering this capability.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1267894
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Subversion 1.6.0 Release Candidate 3 Released
Posted by eg <eg...@gmail.com>.
Bob Archer wrote:
>> Do you have to be running a process to use these? The nice thing
>> about FSEvents is that (IIUC) you can just subscribe the the
>> directory, quit your process, and then comeback later and ask it what
>> changed. It might take some selling to convince the devs and the
>> users that a daemon is needed for Subversion.
>>
>> -Hyrum
>
> I've never used the API directly. But, it looks to me like this is an
> eventing system. If you aren't running a process to respond to the
> events they aren't stored anywhere.
Yes, both the ReadDirectoryChanges and the FindFirstNotification API's
require a process to be running to track all the changes from time A to
time B.
That is why a TortoiseSVN with its explorer shell integration is well
suited for this type of operation.
The only way under Windows to track file or directory changes without
running a process is by using the Change Journal on NTFS file systems only.
see:
http://msdn.microsoft.com/en-us/library/aa363798(VS.85).aspx
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1268124
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Subversion 1.6.0 Release Candidate 3 Released
Posted by Bob Archer <bo...@amsi.com>.
> >> Granted, I'm not very familiar with Windows development and APIs,
but
> >> when I was looking at this for OS X, Linux, and Windows, most
> >> resources I found said there wasn't an equivalent facility on
> >> Windows. Quoting Todd earlier in the thread:
> >
> > Kernal32 has
> >
> > FindFirstChangeNotification
> > FindCloseChangeNotification
> > FindNextChangeNotification
> > WaitForSingleObhject
> >
> > Of course we spoiled .Net devs just use the FileSystemWatcher class
> > which wraps all this up nicely.
>
> Do you have to be running a process to use these? The nice thing
> about FSEvents is that (IIUC) you can just subscribe the the
> directory, quit your process, and then comeback later and ask it what
> changed. It might take some selling to convince the devs and the
> users that a daemon is needed for Subversion.
>
> -Hyrum
I've never used the API directly. But, it looks to me like this is an
eventing system. If you aren't running a process to respond to the
events they aren't stored anywhere.
I'm not sure how it is done now, but can you ask the file system what
has change since a certain time. Rather than comparing every file in the
fs with the .svn files. Just ask the file system what has changed since
a certain date/time and dealing with those issue? Basically doing a dir
where modify date is greater than the last time you checked it? Maybe
that is how it is done now?
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1267850
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Subversion 1.6.0 Release Candidate 3 Released
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Mar 8, 2009, at 5:14 PM, Dave Camp wrote:
> On Mar 4, 2009, at 9:42 AM, Hyrum K. Wright wrote:
>
>> On Mar 4, 2009, at 11:30 AM, Bob Archer wrote:
>> Do you have to be running a process to use these? The nice thing
>> about FSEvents is that (IIUC) you can just subscribe the the
>> directory, quit your process, and then comeback later and ask it what
>> changed. It might take some selling to convince the devs and the
>> users that a daemon is needed for Subversion.
>
> That is not completely accurate. Mac OS X does keep a complete history
> of which directories had changes inside of them. It does not keep any
> history of exactly what files changed in each directory or what the
> nature of the changes were. It is up to client software to determine
> what individual files changed in any given directory.
>
> <http://developer.apple.com/documentation/Darwin/Reference/FSEvents_Ref/FSEvents/
Yeah, I understood the directory-level granularity, but didn't
articulate that very well. However, this would still meet the needs
of Subversion quite well.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1296477
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Subversion 1.6.0 Release Candidate 3 Released
Posted by Dave Camp <da...@thinbits.com>.
On Mar 4, 2009, at 9:42 AM, Hyrum K. Wright wrote:
> On Mar 4, 2009, at 11:30 AM, Bob Archer wrote:
> Do you have to be running a process to use these? The nice thing
> about FSEvents is that (IIUC) you can just subscribe the the
> directory, quit your process, and then comeback later and ask it what
> changed. It might take some selling to convince the devs and the
> users that a daemon is needed for Subversion.
That is not completely accurate. Mac OS X does keep a complete history
of which directories had changes inside of them. It does not keep any
history of exactly what files changed in each directory or what the
nature of the changes were. It is up to client software to determine
what individual files changed in any given directory.
<http://developer.apple.com/documentation/Darwin/Reference/FSEvents_Ref/FSEvents/
>
Dave
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1292014
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Subversion 1.6.0 Release Candidate 3 Released
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Mar 4, 2009, at 11:30 AM, Bob Archer wrote:
>> Granted, I'm not very familiar with Windows development and APIs, but
>> when I was looking at this for OS X, Linux, and Windows, most
>> resources I found said there wasn't an equivalent facility on
>> Windows. Quoting Todd earlier in the thread:
>
> Kernal32 has
>
> FindFirstChangeNotification
> FindCloseChangeNotification
> FindNextChangeNotification
> WaitForSingleObhject
>
> Of course we spoiled .Net devs just use the FileSystemWatcher class
> which wraps all this up nicely.
Do you have to be running a process to use these? The nice thing
about FSEvents is that (IIUC) you can just subscribe the the
directory, quit your process, and then comeback later and ask it what
changed. It might take some selling to convince the devs and the
users that a daemon is needed for Subversion.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1267790
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Subversion 1.6.0 Release Candidate 3 Released
Posted by Bob Archer <bo...@amsi.com>.
> Granted, I'm not very familiar with Windows development and APIs, but
> when I was looking at this for OS X, Linux, and Windows, most
> resources I found said there wasn't an equivalent facility on
> Windows. Quoting Todd earlier in the thread:
Kernal32 has
FindFirstChangeNotification
FindCloseChangeNotification
FindNextChangeNotification
WaitForSingleObhject
Of course we spoiled .Net devs just use the FileSystemWatcher class
which wraps all this up nicely.
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1267750
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Subversion 1.6.0 Release Candidate 3 Released
Posted by km...@rockwellcollins.com.
"Todd C. Gleason" <tg...@impac.com> wrote on 03/04/2009 11:41:21 AM:
> It's been awhile, and there may be better/newer ways to do this but:
>
> http://msdn.microsoft.com/en-us/library/aa364417(VS.85).aspx
>
> And a functional example provided by someone else:
> (I haven't looked at this example, it is just what google found for me)
>
> http://www.codeproject.com/KB/files/directorychangewatcher.aspx
>
> This does require an "active process/thread" to monitor for
> changes, where I believe the OSX stuff can be queried when
> you are interested in the change list...
>
> Kevin R.
>
> After doing a little search of my own? I think the codeproject sample
uses
> the ReadDirectoryChangesW API described at
Yep. Copy and paste error on my part. I was also looking at a few of
the other articles you mentioned below...
Kevin R.
> http://msdn.microsoft.com/en-us/library/aa365465.aspx
>
> And yes, I gather this requires having a dedicated thread. I don?t see
that
> as a problem myself, but there is an alternative: it looks like you can
also
> use FindFirstChangeNotification and FindNextChangeNotification.
>
> There?s an example at
http://www.codeguru.com/cpp/w-p/files/article.php/c4467
> that describes this (actually it describes both approaches), though its
> sample code is confusing. Perhaps a better code sample is at
http://www.
> codeproject.com/KB/system/FolderWatch.aspx . And it appears to have a
caveat
> described at http://support.microsoft.com/kb/188321 where, if you are
> watching a network folder, you need to make sure you have extra
permissions.
>
> If I were implementing this, I?d read the codeguru sample briefly, look
at
> the directorychangewatcher sample from codeproject (which seems to
expose a
> simpler API), and talk with the TortoiseSVN folks to see what code could
be
> leveraged directly from there, as well as what problems they may have
run into.
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1267804
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Subversion 1.6.0 Release Candidate 3 Released
Posted by "Todd C. Gleason" <tg...@impac.com>.
It's been awhile, and there may be better/newer ways to do this but:
http://msdn.microsoft.com/en-us/library/aa364417(VS.85).aspx
And a functional example provided by someone else:
(I haven't looked at this example, it is just what google found for me)
http://www.codeproject.com/KB/files/directorychangewatcher.aspx
This does require an "active process/thread" to monitor for
changes, where I believe the OSX stuff can be queried when
you are interested in the change list...
Kevin R.
After doing a little search of my own... I think the codeproject sample
uses the ReadDirectoryChangesW API described at
http://msdn.microsoft.com/en-us/library/aa365465.aspx
And yes, I gather this requires having a dedicated thread. I don't see
that as a problem myself, but there is an alternative: it looks like
you can also use FindFirstChangeNotification and
FindNextChangeNotification.
There's an example at
http://www.codeguru.com/cpp/w-p/files/article.php/c4467 that describes
this (actually it describes both approaches), though its sample code is
confusing. Perhaps a better code sample is at
http://www.codeproject.com/KB/system/FolderWatch.aspx . And it appears
to have a caveat described at http://support.microsoft.com/kb/188321
where, if you are watching a network folder, you need to make sure you
have extra permissions.
If I were implementing this, I'd read the codeguru sample briefly, look
at the directorychangewatcher sample from codeproject (which seems to
expose a simpler API), and talk with the TortoiseSVN folks to see what
code could be leveraged directly from there, as well as what problems
they may have run into.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1267786
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Subversion 1.6.0 Release Candidate 3 Released
Posted by km...@rockwellcollins.com.
"Todd C. Gleason" <tg...@impac.com> wrote on 03/04/2009 11:11:22 AM:
> > >> There are various thoughts and proposals floating around regarding
> > >> this. I'd personally like to see Subversion tie into the FSEvents
> > >> API
> > >> on OS X and get filesystem change information directly from the
> > >> operating system. Unfortunately, Windows doesn't provide such a
> > >> service yet. :/
> > >
> > > Of course it does. How do you think the TortoiseSVN cache works?
> >
> > Granted, I'm not very familiar with Windows development and APIs, but
> > when I was looking at this for OS X, Linux, and Windows, most
> > resources I found said there wasn't an equivalent facility on
> > Windows. Quoting Todd earlier in the thread:
> >
> > > What I have in mind is systems such as TortoiseSVN where an
> > > optional TSVNCache.exe sits in the background and does this
> > > scanning and handling of file system events so as to update
> > > Windows Explorer icons. (I don't know whether any other
> > > clients do similar things.)"
> >
> > That seems to indicate that TortoiseSVN installs it's own service to
> > look for changes in the filesystem, and that Windows doesn't provide
> > the ability natively. Is that an incorrect assumption?
>
> My understanding is that you can call an API to register for file system
> change events. I don't know the details though off the top of my head.
>
> Presumably TSVNCache registers this event and also does an initial walk
> of the tree when it starts up so it gets into a good initial state.
It's been awhile, and there may be better/newer ways to do this but:
http://msdn.microsoft.com/en-us/library/aa364417(VS.85).aspx
And a functional example provided by someone else:
(I haven't looked at this example, it is just what google found for me)
http://www.codeproject.com/KB/files/directorychangewatcher.aspx
This does require an "active process/thread" to monitor for
changes, where I believe the OSX stuff can be queried when
you are interested in the change list...
Kevin R.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1267746
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Subversion 1.6.0 Release Candidate 3 Released
Posted by "Todd C. Gleason" <tg...@impac.com>.
> >> There are various thoughts and proposals floating around regarding
> >> this. I'd personally like to see Subversion tie into the FSEvents
> >> API
> >> on OS X and get filesystem change information directly from the
> >> operating system. Unfortunately, Windows doesn't provide such a
> >> service yet. :/
> >
> > Of course it does. How do you think the TortoiseSVN cache works?
>
> Granted, I'm not very familiar with Windows development and APIs, but
> when I was looking at this for OS X, Linux, and Windows, most
> resources I found said there wasn't an equivalent facility on
> Windows. Quoting Todd earlier in the thread:
>
> > What I have in mind is systems such as TortoiseSVN where an
> > optional TSVNCache.exe sits in the background and does this
> > scanning and handling of file system events so as to update
> > Windows Explorer icons. (I don't know whether any other
> > clients do similar things.)"
>
> That seems to indicate that TortoiseSVN installs it's own service to
> look for changes in the filesystem, and that Windows doesn't provide
> the ability natively. Is that an incorrect assumption?
My understanding is that you can call an API to register for file system
change events. I don't know the details though off the top of my head.
Presumably TSVNCache registers this event and also does an initial walk
of the tree when it starts up so it gets into a good initial state.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1267685
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Subversion 1.6.0 Release Candidate 3 Released
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Mar 4, 2009, at 10:54 AM, Mark Phippard wrote:
> On Wed, Mar 4, 2009 at 11:36 AM, Hyrum K. Wright
> <hy...@mail.utexas.edu> wrote:
>
>> There are various thoughts and proposals floating around regarding
>> this. I'd personally like to see Subversion tie into the FSEvents
>> API
>> on OS X and get filesystem change information directly from the
>> operating system. Unfortunately, Windows doesn't provide such a
>> service yet. :/
>
> Of course it does. How do you think the TortoiseSVN cache works?
Granted, I'm not very familiar with Windows development and APIs, but
when I was looking at this for OS X, Linux, and Windows, most
resources I found said there wasn't an equivalent facility on
Windows. Quoting Todd earlier in the thread:
> What I have in mind is systems such as TortoiseSVN where an
> optional TSVNCache.exe sits in the background and does this
> scanning and handling of file system events so as to update
> Windows Explorer icons. (I don't know whether any other
> clients do similar things.)"
That seems to indicate that TortoiseSVN installs it's own service to
look for changes in the filesystem, and that Windows doesn't provide
the ability natively. Is that an incorrect assumption?
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1267643
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Subversion 1.6.0 Release Candidate 3 Released
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Mar 4, 2009 at 11:36 AM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> There are various thoughts and proposals floating around regarding
> this. I'd personally like to see Subversion tie into the FSEvents API
> on OS X and get filesystem change information directly from the
> operating system. Unfortunately, Windows doesn't provide such a
> service yet. :/
Of course it does. How do you think the TortoiseSVN cache works?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1267593
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Subversion 1.6.0 Release Candidate 3 Released
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Mar 4, 2009, at 10:30 AM, Gleason, Todd wrote:
>>> 1. Is the .svn-directory-per-directory going away, or just being
>>> replaced with a SQLite representation of data? If it remains, then
>>> presumably you can still copy a subtree elsewhere and work on it.
>>> If it
>>> goes away, then hopefully there will be new commands to achieve the
>>> same
>>> results.
>>
>> All the metadata will be centralized into an sqlite database in the
>> root of the working copy. The pristine copies of stuff (the text
>> bases) will be able to live there, or somewhere else, which is
>> configurable. Straight up copying of a working copy subdirectory
>> will
>> no longer be supported, but we may implement an 'svn detach'
>> subcommand which make it still possible.
>
> Given that this is a currently supported use case, it would be a shame
> to lose it.
Agreed, but empirical evidence suggests that the current detachable
working copy paradigm is not exploited very often.
>
>>
>>> 2. Will there be merely incremental performance enhancements to
>>> operations that appear to scale according to tree size, or are we
>>> going
>>> to see order-of-magnitude or better performance enhancements? And
> to
>>> which operations will they apply? It would be nice in particular to
>>> see
>>> cleanup/update/merge have a better sense of the state of your WC and
>>> run
>>> faster. Even better if stat/commit did not have to scan the whole
>>> tree
>>> (though it seems to me that this would depend on having something
>>> running in the background).
>>
>> We're talking major performance enhancements, both on disk (think one
>> big metadata file instead of hundreds of little ones) and speed.
>> Because the metadata will all live in one place, Subversion will have
>> a much better idea of the current state of the working copy when
>> running commands like cleanup/update/merge/commit. status will still
>> have to walk the working copy looking for unversioned and missing
>> items, but it becomes just a series of stat() calls, instead of
>> reading and parsing hundreds of metadata files. In all, we expect
>> some pretty serious gains (though they are difficult to quantify
>> without having actually written and profiled the code).
>
> That sounds like a terrific improvement overall. Allow me to
> suggest a
> way for third-parties to integrate: If an external program wants to
> walk the tree and also install its own hook that gets notified on file
> system events, let it also notify the Subversion metadata such that it
> won't always be necessary even for status to walk the WC.
>
> What I have in mind is systems such as TortoiseSVN where an optional
> TSVNCache.exe sits in the background and does this scanning and
> handling
> of file system events so as to update Windows Explorer icons. (I
> don't
> know whether any other clients do similar things.)
>
> Of course, Subversion could conceivably do this internally too, as an
> optional daemon/service. It would probably need a central registry of
> WCs to watch, and if the user moved or copied a WC it might have to
> re-scan a WC on a subsequent svn command (and update the registry).
There are various thoughts and proposals floating around regarding
this. I'd personally like to see Subversion tie into the FSEvents API
on OS X and get filesystem change information directly from the
operating system. Unfortunately, Windows doesn't provide such a
service yet. :/
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1267538
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Subversion 1.6.0 Release Candidate 3 Released
Posted by "Todd C. Gleason" <tg...@impac.com>.
> > 1. Is the .svn-directory-per-directory going away, or just being
> > replaced with a SQLite representation of data? If it remains, then
> > presumably you can still copy a subtree elsewhere and work on it.
> > If it
> > goes away, then hopefully there will be new commands to achieve the
> > same
> > results.
>
> All the metadata will be centralized into an sqlite database in the
> root of the working copy. The pristine copies of stuff (the text
> bases) will be able to live there, or somewhere else, which is
> configurable. Straight up copying of a working copy subdirectory will
> no longer be supported, but we may implement an 'svn detach'
> subcommand which make it still possible.
Given that this is a currently supported use case, it would be a shame
to lose it.
>
> > 2. Will there be merely incremental performance enhancements to
> > operations that appear to scale according to tree size, or are we
> > going
> > to see order-of-magnitude or better performance enhancements? And
to
> > which operations will they apply? It would be nice in particular to
> > see
> > cleanup/update/merge have a better sense of the state of your WC and
> > run
> > faster. Even better if stat/commit did not have to scan the whole
> > tree
> > (though it seems to me that this would depend on having something
> > running in the background).
>
> We're talking major performance enhancements, both on disk (think one
> big metadata file instead of hundreds of little ones) and speed.
> Because the metadata will all live in one place, Subversion will have
> a much better idea of the current state of the working copy when
> running commands like cleanup/update/merge/commit. status will still
> have to walk the working copy looking for unversioned and missing
> items, but it becomes just a series of stat() calls, instead of
> reading and parsing hundreds of metadata files. In all, we expect
> some pretty serious gains (though they are difficult to quantify
> without having actually written and profiled the code).
That sounds like a terrific improvement overall. Allow me to suggest a
way for third-parties to integrate: If an external program wants to
walk the tree and also install its own hook that gets notified on file
system events, let it also notify the Subversion metadata such that it
won't always be necessary even for status to walk the WC.
What I have in mind is systems such as TortoiseSVN where an optional
TSVNCache.exe sits in the background and does this scanning and handling
of file system events so as to update Windows Explorer icons. (I don't
know whether any other clients do similar things.)
Of course, Subversion could conceivably do this internally too, as an
optional daemon/service. It would probably need a central registry of
WCs to watch, and if the user moved or copied a WC it might have to
re-scan a WC on a subsequent svn command (and update the registry).
> The other big win is that the APIs and other code surrounding the
> working copy library will be much simpler and more compact, helping
> further development progress more rapidly.
It sounds like it. I hope the implementation goes well, because I'm
already looking forward to 1.7, and 1.6 isn't even released!
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1267521
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Subversion 1.6.0 Release Candidate 3 Released
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Mar 4, 2009, at 2:44 AM, Stephen Connolly wrote:
>
>
> 2009/3/4 Hyrum K. Wright <hy...@mail.utexas.edu>
> On Mar 3, 2009, at 6:26 PM, Todd C. Gleason wrote:
>
> >>> Personally, I'd really like to know what are going to be the
> >>> implications of using SQLite on the client to store metadata, even
> > if
> >>> it's not until 1.7.
> >>
> >> What particular implications? It will have performance
> enhancements,
> >> to be sure. We'll let SQLite do a fair amount of the concurrency
> >> handling which Subversion core currently has to do, and also let it
> >> optimize the data layout. The code should get much saner for
> future
> >> developers adding new features. Users shouldn't notice anything
> >> incredibly different, save the speed improvements.
> >
> > The kind of things I'm wondering are (and forgive me if my questions
> > betray my ignorance of svn internals):
>
> No problem. You aren't expected to know the internals of Subversion.
> (Heck, *I'm* still trying to figure some of them out!)
>
> > 1. Is the .svn-directory-per-directory going away, or just being
> > replaced with a SQLite representation of data? If it remains, then
> > presumably you can still copy a subtree elsewhere and work on it.
> > If it
> > goes away, then hopefully there will be new commands to achieve the
> > same
> > results.
>
> All the metadata will be centralized into an sqlite database in the
> root of the working copy. The pristine copies of stuff (the text
> bases) will be able to live there, or somewhere else, which is
> configurable. Straight up copying of a working copy subdirectory will
> no longer be supported, but we may implement an 'svn detach'
> subcommand which make it still possible.
>
> So will the svn commands, when executed in a subdirectory walk up
> the tree looking for the metadata directory? or will all svn
> commands have to be executed in the root of the checkout?
They will walk up the tree to find the appropriate metadata store.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1267185
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Subversion 1.6.0 Release Candidate 3 Released
Posted by Stephen Connolly <st...@gmail.com>.
2009/3/4 Hyrum K. Wright <hy...@mail.utexas.edu>
> On Mar 3, 2009, at 6:26 PM, Todd C. Gleason wrote:
>
> >>> Personally, I'd really like to know what are going to be the
> >>> implications of using SQLite on the client to store metadata, even
> > if
> >>> it's not until 1.7.
> >>
> >> What particular implications? It will have performance enhancements,
> >> to be sure. We'll let SQLite do a fair amount of the concurrency
> >> handling which Subversion core currently has to do, and also let it
> >> optimize the data layout. The code should get much saner for future
> >> developers adding new features. Users shouldn't notice anything
> >> incredibly different, save the speed improvements.
> >
> > The kind of things I'm wondering are (and forgive me if my questions
> > betray my ignorance of svn internals):
>
> No problem. You aren't expected to know the internals of Subversion.
> (Heck, *I'm* still trying to figure some of them out!)
>
> > 1. Is the .svn-directory-per-directory going away, or just being
> > replaced with a SQLite representation of data? If it remains, then
> > presumably you can still copy a subtree elsewhere and work on it.
> > If it
> > goes away, then hopefully there will be new commands to achieve the
> > same
> > results.
>
> All the metadata will be centralized into an sqlite database in the
> root of the working copy. The pristine copies of stuff (the text
> bases) will be able to live there, or somewhere else, which is
> configurable. Straight up copying of a working copy subdirectory will
> no longer be supported, but we may implement an 'svn detach'
> subcommand which make it still possible.
So will the svn commands, when executed in a subdirectory walk up the tree
looking for the metadata directory? or will all svn commands have to be
executed in the root of the checkout?
>
>
> > 2. Will there be merely incremental performance enhancements to
> > operations that appear to scale according to tree size, or are we
> > going
> > to see order-of-magnitude or better performance enhancements? And to
> > which operations will they apply? It would be nice in particular to
> > see
> > cleanup/update/merge have a better sense of the state of your WC and
> > run
> > faster. Even better if stat/commit did not have to scan the whole
> > tree
> > (though it seems to me that this would depend on having something
> > running in the background).
>
> We're talking major performance enhancements, both on disk (think one
> big metadata file instead of hundreds of little ones) and speed.
> Because the metadata will all live in one place, Subversion will have
> a much better idea of the current state of the working copy when
> running commands like cleanup/update/merge/commit. status will still
> have to walk the working copy looking for unversioned and missing
> items, but it becomes just a series of stat() calls, instead of
> reading and parsing hundreds of metadata files. In all, we expect
> some pretty serious gains (though they are difficult to quantify
> without having actually written and profiled the code).
>
> The other big win is that the APIs and other code surrounding the
> working copy library will be much simpler and more compact, helping
> further development progress more rapidly.
>
> -Hyrum
>
> ------------------------------------------------------
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1265095
>
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe@subversion.tigris.org].
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1265735
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Subversion 1.6.0 Release Candidate 3 Released
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Mar 3, 2009, at 6:26 PM, Todd C. Gleason wrote:
>>> Personally, I'd really like to know what are going to be the
>>> implications of using SQLite on the client to store metadata, even
> if
>>> it's not until 1.7.
>>
>> What particular implications? It will have performance enhancements,
>> to be sure. We'll let SQLite do a fair amount of the concurrency
>> handling which Subversion core currently has to do, and also let it
>> optimize the data layout. The code should get much saner for future
>> developers adding new features. Users shouldn't notice anything
>> incredibly different, save the speed improvements.
>
> The kind of things I'm wondering are (and forgive me if my questions
> betray my ignorance of svn internals):
No problem. You aren't expected to know the internals of Subversion.
(Heck, *I'm* still trying to figure some of them out!)
> 1. Is the .svn-directory-per-directory going away, or just being
> replaced with a SQLite representation of data? If it remains, then
> presumably you can still copy a subtree elsewhere and work on it.
> If it
> goes away, then hopefully there will be new commands to achieve the
> same
> results.
All the metadata will be centralized into an sqlite database in the
root of the working copy. The pristine copies of stuff (the text
bases) will be able to live there, or somewhere else, which is
configurable. Straight up copying of a working copy subdirectory will
no longer be supported, but we may implement an 'svn detach'
subcommand which make it still possible.
> 2. Will there be merely incremental performance enhancements to
> operations that appear to scale according to tree size, or are we
> going
> to see order-of-magnitude or better performance enhancements? And to
> which operations will they apply? It would be nice in particular to
> see
> cleanup/update/merge have a better sense of the state of your WC and
> run
> faster. Even better if stat/commit did not have to scan the whole
> tree
> (though it seems to me that this would depend on having something
> running in the background).
We're talking major performance enhancements, both on disk (think one
big metadata file instead of hundreds of little ones) and speed.
Because the metadata will all live in one place, Subversion will have
a much better idea of the current state of the working copy when
running commands like cleanup/update/merge/commit. status will still
have to walk the working copy looking for unversioned and missing
items, but it becomes just a series of stat() calls, instead of
reading and parsing hundreds of metadata files. In all, we expect
some pretty serious gains (though they are difficult to quantify
without having actually written and profiled the code).
The other big win is that the APIs and other code surrounding the
working copy library will be much simpler and more compact, helping
further development progress more rapidly.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1265095
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Subversion 1.6.0 Release Candidate 3 Released
Posted by "Todd C. Gleason" <tg...@impac.com>.
> > Personally, I'd really like to know what are going to be the
> > implications of using SQLite on the client to store metadata, even
if
> > it's not until 1.7.
>
> What particular implications? It will have performance enhancements,
> to be sure. We'll let SQLite do a fair amount of the concurrency
> handling which Subversion core currently has to do, and also let it
> optimize the data layout. The code should get much saner for future
> developers adding new features. Users shouldn't notice anything
> incredibly different, save the speed improvements.
The kind of things I'm wondering are (and forgive me if my questions
betray my ignorance of svn internals):
1. Is the .svn-directory-per-directory going away, or just being
replaced with a SQLite representation of data? If it remains, then
presumably you can still copy a subtree elsewhere and work on it. If it
goes away, then hopefully there will be new commands to achieve the same
results.
2. Will there be merely incremental performance enhancements to
operations that appear to scale according to tree size, or are we going
to see order-of-magnitude or better performance enhancements? And to
which operations will they apply? It would be nice in particular to see
cleanup/update/merge have a better sense of the state of your WC and run
faster. Even better if stat/commit did not have to scan the whole tree
(though it seems to me that this would depend on having something
running in the background).
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1264132
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Subversion 1.6.0 Release Candidate 3 Released
Posted by "Gleason, Todd" <tg...@impac.com>.
> -----Original Message-----
> From: Hyrum K. Wright [mailto:hyrum_wright@mail.utexas.edu]
> Sent: Monday, March 02, 2009 1:02 PM
> To: Bob Archer
> Cc: dev@subversion.tigris.org; subversion-users
> Subject: Re: Subversion 1.6.0 Release Candidate 3 Released
>
> [ when responding to release announcements, please only include
> users@subversion.tigris.org
> in the To: or CC: fields. I'm including dev@ in the CC: for this
> mail so users there will know it has been answered, please remove it
> from subsequent replies. ]
>
> The Subversion project does not publish binary installers or
> packages. It will be up to the individual package maintainers to
> determine how they choose to include or link SQLite against
Subversion.
>
> That being said, the developers gone to great lengths in the build
> system to ensure that SQLite can be built as part of Subversion
> proper, or that existing SQLite installations can be used. Packagers
> should choose whatever is suitable for their platform.
>
> In 1.6, SQLite is used as part of the FSFS backend for rep-sharing,
> and in 1.7 it will be used on the client to store working copy
metadata.
http://subversion.tigris.org/svn_1.6_releasenotes.html simply reads:
XXX: We now require SQLite for both the server and client.
Obviously the release notes aren't done yet, but I suspect this is why
the question came about. Presumably it isn't actually required for the
1.6 client then?
Personally, I'd really like to know what are going to be the
implications of using SQLite on the client to store metadata, even if
it's not until 1.7.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1258782
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Subversion 1.6.0 Release Candidate 3 Released
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
[ when responding to release announcements, please only include users@subversion.tigris.org
in the To: or CC: fields. I'm including dev@ in the CC: for this
mail so users there will know it has been answered, please remove it
from subsequent replies. ]
The Subversion project does not publish binary installers or
packages. It will be up to the individual package maintainers to
determine how they choose to include or link SQLite against Subversion.
That being said, the developers gone to great lengths in the build
system to ensure that SQLite can be built as part of Subversion
proper, or that existing SQLite installations can be used. Packagers
should choose whatever is suitable for their platform.
In 1.6, SQLite is used as part of the FSFS backend for rep-sharing,
and in 1.7 it will be used on the client to store working copy metadata.
-Hyrum
On Mar 2, 2009, at 1:47 PM, Bob Archer wrote:
> What does the SQLite dependency mean to people using the binary
> installers? I am assuming nothing and that SQLite will be packaged in
> the installers as needed. Or are we going to need to install SQLite
> now?
>
> How is sqllite used? Does the working copy metadata now get stored
> in a
> SQLite database?
>
> BOb
>
>
>> Release notes for the 1.6.x release series may be found at:
>>
>> http://subversion.tigris.org/svn_1.6_releasenotes.html
>>
>> You can find the list of changes between 1.6.0-rc3 and earlier
>> versions at:
>>
>> http://svn.collab.net/repos/svn/tags/1.6.0-rc3/CHANGES
>>
>> Questions, comments, and bug reports to users@subversion.tigris.org.
>>
>> Thanks,
>> - The Subversion Team
>>
>> ------------------------------------------------------
>>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageI
> d=
>> 1257674
>>
>> To unsubscribe from this discussion, e-mail: [users-
>> unsubscribe@subversion.tigris.org].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1258042
RE: Subversion 1.6.0 Release Candidate 3 Released
Posted by Bob Archer <bo...@amsi.com>.
What does the SQLite dependency mean to people using the binary
installers? I am assuming nothing and that SQLite will be packaged in
the installers as needed. Or are we going to need to install SQLite now?
How is sqllite used? Does the working copy metadata now get stored in a
SQLite database?
BOb
> Release notes for the 1.6.x release series may be found at:
>
> http://subversion.tigris.org/svn_1.6_releasenotes.html
>
> You can find the list of changes between 1.6.0-rc3 and earlier
> versions at:
>
> http://svn.collab.net/repos/svn/tags/1.6.0-rc3/CHANGES
>
> Questions, comments, and bug reports to users@subversion.tigris.org.
>
> Thanks,
> - The Subversion Team
>
> ------------------------------------------------------
>
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageI
d=
> 1257674
>
> To unsubscribe from this discussion, e-mail: [users-
> unsubscribe@subversion.tigris.org].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1257906
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Subversion 1.6.0 Release Candidate 3 Released
Posted by Bob Archer <bo...@amsi.com>.
What does the SQLite dependency mean to people using the binary
installers? I am assuming nothing and that SQLite will be packaged in
the installers as needed. Or are we going to need to install SQLite now?
How is sqllite used? Does the working copy metadata now get stored in a
SQLite database?
BOb
> Release notes for the 1.6.x release series may be found at:
>
> http://subversion.tigris.org/svn_1.6_releasenotes.html
>
> You can find the list of changes between 1.6.0-rc3 and earlier
> versions at:
>
> http://svn.collab.net/repos/svn/tags/1.6.0-rc3/CHANGES
>
> Questions, comments, and bug reports to users@subversion.tigris.org.
>
> Thanks,
> - The Subversion Team
>
> ------------------------------------------------------
>
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageI
d=
> 1257674
>
> To unsubscribe from this discussion, e-mail: [users-
> unsubscribe@subversion.tigris.org].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1257906
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].