After defragmenting my disk and running 'svn up' I see that many entries
files are re-written (and fragmented), yet no files had changed.
Why is this? I'm running Tortoise SVN 64bit Windows.
Thanks,
David
On Tue, Aug 10, 2010 at 7:07 PM, David Weintraub wrote:
> On Mon, Aug 9, 2010 at 1:04 PM, Andreas Kotes wrote:
>> Hello,
>>
>> how good/bad an idea is storing large amounts of medium-sized files
>> (think Yum/RPM repositories with full CentOS/EPEL releases) in
>> SVN for rollback and other purpos
On Mon, Aug 9, 2010 at 1:04 PM, Andreas Kotes wrote:
> Hello,
>
> how good/bad an idea is storing large amounts of medium-sized files
> (think Yum/RPM repositories with full CentOS/EPEL releases) in
> SVN for rollback and other purposes?
The big problem with Subversion is that you cannot (easily)
On 2010-08-10 20:59:00 +0200, Stefan Sperling wrote:
> On Tue, Aug 10, 2010 at 07:44:35PM +0200, Vincent Lefevre wrote:
> > This is easy (at least from the specification point of view): once the
> > encoding has been determined[*], typically at checkout time, store the
> > encoding in the WC metada
> Anyone got a quick and dirty way to determine how long ago was the
> last
> commit? I want to change my build system to not start a build if
> there
> was a very recent checkin. That way if someone is checking in a
> group of
> changes, I don't end up kicking off a build in the middle and then
>
On Tue, Aug 10, 2010 at 16:54, Jeremy Mordkoff wrote:
> Anyone got a quick and dirty way to determine how long ago was the last
> commit? I want to change my build system to not start a build if there
> was a very recent checkin. That way if someone is checking in a group of
> changes, I don't end
Anyone got a quick and dirty way to determine how long ago was the last
commit? I want to change my build system to not start a build if there
was a very recent checkin. That way if someone is checking in a group of
changes, I don't end up kicking off a build in the middle and then
having to wait f
On Tue, Aug 10, 2010 at 07:44:35PM +0200, Vincent Lefevre wrote:
> On 2010-08-10 17:42:57 +0200, Stefan Sperling wrote:
> > There are extensions in some systems like Linux, where filename encoding
> > can be specified at mount time and a process can query this information.
> > But the actual encodi
On 2010-08-10 09:27:50 -0700, David Brodbeck wrote:
> On Aug 10, 2010, at 7:12 AM, Vincent Lefevre wrote:
> > After a repository upgrade with svn version 1.5.1 (r32289) a few days
> > ago, we now get the following error when committing:
> >
> > svn: Can't open file '/svn/mpfr/db/txn-current-lock':
On 2010-08-10 17:42:57 +0200, Stefan Sperling wrote:
> The locale only matters when data is presented to the user (by the svn
> client, or svnlook, or svnadmin, ...) in which case Subversion uses iconv
> to translate the UTF-8 data into the character set of the current locale.
The svn client also
On Aug 10, 2010, at 7:12 AM, Vincent Lefevre wrote:
> After a repository upgrade with svn version 1.5.1 (r32289) a few days
> ago, we now get the following error when committing:
>
> svn: Can't open file '/svn/mpfr/db/txn-current-lock': Permission denied
>
> No problems for read operations.
I
On Tue, Aug 10, 2010 at 04:59:58PM +0200, Vincent Lefevre wrote:
> On 2010-08-09 19:30:00 +0300, Daniel Shahaf wrote:
> > In the repository filesystem, we use UTF-8 exclusively. APR handles
> > translating that UTF-8 to whatever the local OS supports.
>
> Which is meaningless, since under Unix, t
On 8/10/2010 9:26 AM, Tom Malia wrote:
I’m managing a project that includes about a half a dozen developers and
they have an existing SVN repo that most people have been using
basically as a network share. PLEASE don’t swamp me with all the “Well,
they are just going to have to learn Subversion!”
On 2010-08-09 19:30:00 +0300, Daniel Shahaf wrote:
> In the repository filesystem, we use UTF-8 exclusively. APR handles
> translating that UTF-8 to whatever the local OS supports.
Which is meaningless, since under Unix, the locale is not related
to the OS, but to the process: one can have a shel
On 2010-08-10 16:12:15 +0200, Vincent Lefevre wrote:
> After a repository upgrade with svn version 1.5.1 (r32289) a few days
Note: the upgrade was done with:
svnadmin upgrade /svnroot/mpfr
svn-populate-node-origins-index /svnroot/mpfr
> ago, we now get the following error when committing:
>
I'm managing a project that includes about a half a dozen developers and
they have an existing SVN repo that most people have been using basically as
a network share. PLEASE don't swamp me with all the "Well, they are just
going to have to learn Subversion!" comments. I know what would be best bu
After a repository upgrade with svn version 1.5.1 (r32289) a few days
ago, we now get the following error when committing:
svn: Can't open file '/svn/mpfr/db/txn-current-lock': Permission denied
No problems for read operations.
The DB FS type is FSFS, and we have:
vlefe...@ff-scm-prod:~$ ls -l
17 matches
Mail list logo
