On 10/2/2013 10:36 AM, Ullrich Jans wrote:
I'm now facing the same problem. My users want the rebasing, but during
the dump/load instead of after the fact (apparently, it causes issues
with their environment when they need to go back to an earlier revision
to reproduce something). They also
Am 10.09.2013 19:45, schrieb Thomas Harold:
When we moved from a monolithic repository to per-client repositories a
few years ago, we went ahead and:
- Rebased the paths up one or two levels (old system was something like
monolithicrepo/[a-z]/[client directories]/[job directory]) so that the
Am 10.09.2013 19:45, schrieb Thomas Harold:
When we moved from a monolithic repository to per-client repositories
a few years ago, we went ahead and:
- Rebased the paths up one or two levels (old system was something
like monolithicrepo/[a-z]/[client directories]/[job directory]) so
On Wed, Sep 11, 2013 at 10:49 PM, Nico Kadel-Garcia nka...@gmail.com wrote:
Les, disk space isn't the issue for the empty revs. It's any operations that
try to scan or assemble information from the revisions. 5000 empty objects
is still a logistical burden, especially if assembling any kind of
Les, disk space isn't the issue for the empty revs. It's any operations
that try to scan or assemble information from the revisions. 5000 empty
objects is still a logistical burden, especially if assembling any kind
of change history for the new repository. And since the new repositories
are
Guten Tag Trent W. Buck,
am Dienstag, 10. September 2013 um 02:49 schrieben Sie:
...hm, still 1.6. Is it worth me backporting a newer svn?
I would give it a try, get yourself a current build of 1.8, dump your
old repo and load it into a newly created from your 1.8 version and
see how much
On 9/9/2013 8:49 PM, Trent W. Buck wrote:
I'm partway through provisioning the replacement Debian 7 server, which
will have
subversion 1.6.17dfsg-4+deb7u3
apache22.2.22-13
...hm, still 1.6. Is it worth me backporting a newer svn?
Yes, it's worth installing 1.8.3.
Have you checked if the users have/need anything (emails, ticket
system, etc.) that refer to specific revisions or the history of
changes made there? It seems kind of drastic to throw that away
because you think the numbers aren't pretty enough.
But keeping thousands of empty commits in a
On Tue, Sep 10, 2013 at 6:22 AM, Nico Kadel-Garcia nka...@gmail.com wrote:
Even if the history is considered sacrosanct (and this is often a
theological policy, not an engineering one!), an opportunity to reduce the
size of each reaporitory by discarding deadwood at switchover time should be
On 9/10/2013 7:22 AM, Nico Kadel-Garcia wrote:
But keeping thousands of empty commits in a project they're not relevant
to is confusing and wasteful. The repository and repository URL's for
the old project should be preserved, if possible, locked down and
read-only, precisely for this kind of
-Original Message-
From: t...@elba.apache.org [mailto:t...@elba.apache.org] On Behalf Of Trent
W. Buck
Sent: Monday, September 09, 2013 11:38 PM
To: users@subversion.apache.org
Subject: Re: Breaking up a monolothic repository
Les Mikesell lesmikes...@gmail.com writes:
On Mon
On Tue, Sep 10, 2013 at 4:36 PM, Bob Archer bob.arc...@amsi.com wrote:
Also part of the reason to split up the repos is to make access
control easier, and it looks bad if Alice (who should have access to
project 1 but not project 2) can see Bob's old commit metadata to
project 2, even if
Guten Tag Trent W. Buck,
am Montag, 9. September 2013 um 03:13 schrieben Sie:
What else can I do?
Tell us about the size of your repo, it's format version and primary
data types versioned, as you always can simply clone the entire repo
into one for each project needed and delete and move
On Sun, Sep 8, 2013 at 8:13 PM, Trent W. Buck trentb...@gmail.com wrote:
I'm stuck. Since it's no fun to have tens of thousands of empty revs
in each project repo, my current approach is to leave existing
projects in the monolithic repo, and new projects get separate repos.
Why do you think
W. Buck
Cc: Subversion
Subject: Re: Breaking up a monolothic repository
On Sun, Sep 8, 2013 at 8:13 PM, Trent W. Buck trentb...@gmail.com wrote:
I'm stuck. Since it's no fun to have tens of thousands of empty revs
in each project repo, my current approach is to leave existing
projects
On Mon, Sep 9, 2013 at 8:03 AM, Grierson, David
david.grier...@bskyb.com wrote:
I can see Trent's view point that people are weird and get freaked out by the
unexpected (where they might expect the revision numbers to be relatively
low).
I could see that for someone who had never used
On Sep 9, 2013, at 07:31, Les Mikesell wrote:
On Sun, Sep 8, 2013 at 8:13 PM, Trent W. Buck wrote:
I'm stuck. Since it's no fun to have tens of thousands of empty revs
in each project repo, my current approach is to leave existing
projects in the monolithic repo, and new projects get
Ryan Schmidt subversion-20...@ryandesign.com writes:
As someone used to Subversion's usually sequential revision numbers,
that bugs me aesthetically, but it works fine.
I think that's the crux of it. Also part of the reason to split up the
repos is to make access control easier, and it looks
Thorsten Schöning tschoen...@am-soft.de writes:
Tell us about the size of your repo
it's format version and primary data types versioned
(Sorry for not giving this info earlier, and shifting the goal posts --
I personally went rcs-arch-darcs-git and never really used svn, so
I'm feeling pretty
trentb...@gmail.com (Trent W. Buck) writes:
So then I thought to chain the two approaches. This didn't work -- the
empty revs were not removed. I guess svndumpfilter --drop-empty-revs
is only smart enough to drop the revs that have just *become* empty?
rm -rf delete-me-3
svnadmin
On Mon, Sep 9, 2013 at 7:23 PM, Trent W. Buck trentb...@gmail.com wrote:
Ryan Schmidt subversion-20...@ryandesign.com writes:
As someone used to Subversion's usually sequential revision numbers,
that bugs me aesthetically, but it works fine.
I think that's the crux of it.
Have you checked
Les Mikesell lesmikes...@gmail.com writes:
On Mon, Sep 9, 2013 at 7:23 PM, Trent W. Buck trentb...@gmail.com wrote:
Ryan Schmidt subversion-20...@ryandesign.com writes:
As someone used to Subversion's usually sequential revision numbers,
that bugs me aesthetically, but it works fine.
I
I have inherited a single monolithic repo for all the company's
projects. I want to migrate to one repo per project. (One-way,
one-time migration.)
Following the red-bean book[0], I first tried svnadmin, which was
really slow, and eventually crashed because some files were copied
into
Lock the existing repo: Do clean exports, and imports, to new repositories
with the new layout, with a README.md or other guideline to where the
legacy repository exists. You lose the infinitely preserved history this
way, but for most working software projects, you don't *need* that. And
it's a
Nico Kadel-Garcia nka...@gmail.com writes:
Lock the existing repo: Do clean exports, and imports, to new repositories
with the new layout, with a README.md or other guideline to where the
legacy repository exists. You lose the infinitely preserved history this
way, but for most working
From: Trent W. Buck
Sent: Monday, 9 September 2013 12:17 PM
Nico Kadel-Garcia nka...@gmail.com writes:
Lock the existing repo: Do clean exports, and imports, to new
repositories with the new layout, with a README.md or other
guideline
to where the legacy repository exists. You lose
Geoff Field geoff_fi...@aapl.com.au writes:
I get the impression that $company's projects mostly have a finite
lifespan (a couple of years),
By lifespan, what exactly do you mean? At my company, the
individual projects might be in production within anywhere from 6
months to 2 years after
27 matches
Mail list logo
