Guten Tag olli hauer,
am Mittwoch, 28. November 2012 um 22:45 schrieben Sie:
> Someone hacks one of the additional mirrors, modifies a revision and adjust
> the
> checksum (as described on many places how-to fix a corrupt repo) so it looks
> OK
> even with svnadmin verify.
Sounds interesting, b
Guten Tag Karla Sylvester,
am Mittwoch, 28. November 2012 um 22:17 schrieben Sie:
> This seem happened after I upgraded Slik-Subversion to 1.7.7 (from
> 1.7.5, I believe). The same thing is happening on two different
> machines, both Windows. When I do a checkout from a Linux machine, I
> hav
There were some binary files that were included as part of the projects
that weren't necessary, so its tons of seemingly small mistakes.
The repository was started 5 1/2 years ago. Revision #6,000 was about 2
years ago. I have never used any history older than 24 months.
Even though 10 GB doesn
On 2012-11-25 21:49, Thorsten Schöning wrote:
> Guten Tag olli hauer,
> am Sonntag, 25. November 2012 um 20:18 schrieben Sie:
>
>> Thanks for every answer and code snippet ...
>
> I'm interested in which problem you try to solve with your approach?
> What's the reason behind it? Maybe there are o
On Wed, Nov 28, 2012 at 3:18 PM, Thorsten Schöning
wrote:
>>
>> Does the answer change based on this?
>
> One can maybe make more clear why removing versions may have not the
> desired effect at all and is therefore just a waste of time. Your
> accidently committed and never changed images are one
On Wed, Nov 28, 2012 at 4:18 PM, Matthew Bluhm wrote:
> My repository is now over 10GB and it is rather cumbersome to take care of.
>
> There has been many mistakes such as committing extra files.
>
> The older revisions provide no value and only cause headaches.
>
> I initially thought that I cou
This seem happened after I upgraded Slik-Subversion to 1.7.7 (from
1.7.5, I believe). The same thing is happening on two different
machines, both Windows. When I do a checkout from a Linux machine, I
have no problem.
Thanks for the help,
--
Karla Sylvester
Senior Software Engineer
Wegmann U
My repository is now over 10GB and it is rather cumbersome to take care of.
There has been many mistakes such as committing extra files.
The older revisions provide no value and only cause headaches.
I initially thought that I could export out the repository at revision
6,000 then just apply a d
Guten Tag Les Mikesell,
am Mittwoch, 28. November 2012 um 22:00 schrieben Sie:
> Does the answer change based on this?
One can maybe make more clear why removing versions may have not the
desired effect at all and is therefore just a waste of time. Your
accidently committed and never changed imag
On Wed, Nov 28, 2012 at 3:42 PM, Les Mikesell wrote:
> On Wed, Nov 28, 2012 at 2:36 PM, Andy Levy wrote:
> >
> >> Is there an easy way to purge out the earliest 6,000 Revisions of the
> >> 9,600 that are in my repository?
> >>
> >> In a perfect world I would keep my revision numbers and timestam
Guten Tag Daniel Shahaf,
am Mittwoch, 28. November 2012 um 21:36 schrieben Sie:
> And that's one of the reasons behind the standard recommendation not to
> access a single working copy from multiple systems, especally windows
> and non-windows.
Thanks, looks like I would really be better off chan
On Wed, Nov 28, 2012 at 2:50 PM, Thorsten Schöning
wrote:
> Guten Tag Les Mikesell,
> am Mittwoch, 28. November 2012 um 21:42 schrieben Sie:
>
>> It's pretty much just a matter of time until someone does something
>> that shouldn't have been done in any repository. Even if the answer
>> is always
Guten Tag Les Mikesell,
am Mittwoch, 28. November 2012 um 21:42 schrieben Sie:
> It's pretty much just a matter of time until someone does something
> that shouldn't have been done in any repository. Even if the answer
> is always going to be 'it can't be done', why question the motives of
> some
On Wed, Nov 28, 2012 at 2:36 PM, Andy Levy wrote:
>
>> Is there an easy way to purge out the earliest 6,000 Revisions of the
>> 9,600 that are in my repository?
>>
>> In a perfect world I would keep my revision numbers and timestamps, but
>> that isn't 100% required.
>>
>
> Short answer: No.
>
> L
On Wed, Nov 28, 2012 at 3:10 PM, Matthew Bluhm wrote:
>
> Is there an easy way to purge out the earliest 6,000 Revisions of the
> 9,600 that are in my repository?
>
> In a perfect world I would keep my revision numbers and timestamps, but
> that isn't 100% required.
>
>
Short answer: No.
Longer a
Thorsten Schöning wrote on Wed, Nov 28, 2012 at 18:13:44 +0100:
> Hello,
>
> I have some working copies on Samba shares, Ubuntu 12.04 LTS with all
> updates installed, which are accessed using TortoiseSVN 1.7.10 which
> uses Subversion 1.7.7. Some of those working copies contain executable
> Perl
Is there an easy way to purge out the earliest 6,000 Revisions of the 9,600
that are in my repository?
In a perfect world I would keep my revision numbers and timestamps, but
that isn't 100% required.
Hello, Armando.
Here we also do IEC / ISO workflows. We use the same svn repository
for all kind of artifacts (source code, specs, reports, schematics...).
We use tags for everything. For instance, we tag the documents alongside
the reports that 'prove' that have been reviewed by who and when.
T
Hello,
I have some working copies on Samba shares, Ubuntu 12.04 LTS with all
updates installed, which are accessed using TortoiseSVN 1.7.10 which
uses Subversion 1.7.7. Some of those working copies contain executable
Perl scripts with proper svn:executable defined as *, but depending on
my Samba c
Yes, it was the SELinux messing with my life again, it works now!
(it actually saved my afternoon, I was debugging it for a loog time already)
Since this is a test//prototype environment, I've turned the SELinux it off
completely (is ok for me). However, it would be nice to know how to properly
Guten Tag armando.perico.n...@usi.ch,
am Mittwoch, 28. November 2012 um 16:43 schrieben Sie:
> svn: OPTIONS of 'http://localhost/svn/repo/test.txt": could not
> connect to server (http://localhost)
SELInux or AppArmor may prevent communication as both work on binaries
I think, not on users, there
Hi,
I want to write a pre-commit hook which make some checks on the repository
using "svn" commands. i.e.: svn ls... however, svn ls is failing to connect to
localhost.
on my pre-commit file I have:
---
# I don't need the $REPOS value since this is ju
Guten Tag Niemann, Hartmut,
am Mittwoch, 28. November 2012 um 12:42 schrieben Sie:
> But how should one recover in such a situation?
> Is a fresh checkout and a manual merge necessary?
Yes, the missing versions between you backup and the current working
copy are lost and your working copies can
Wed, Nov 28, 2012 at 6:42 AM, Niemann, Hartmut wrote:
> **
> Hello!
> Our SVN server had a disk failure and some projects had to be restored
> from the nightly backup.
>
> What happens in such a case, if my working copy is on revision 120 and the
> latest revision in the restored archive is 110?
Niemann, Hartmut wrote on Wed, Nov 28, 2012 at 12:42:44 +0100:
> So at least it looks like a newer working copy can not be overwritten
> incidentially by the restored (older) HEAD revision.
It's not that simple --- once you commit 11 revisions to the restored
repository, you'll get some... intere
Hello!
Our SVN server had a disk failure and some projects had to be restored from the
nightly backup.
What happens in such a case, if my working copy is on revision 120 and the
latest revision in the restored archive is 110?
I did some tests and it looks like subversion detects that (I used To
26 matches
Mail list logo
