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 want
> 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 dire
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
On Wed, Sep 11, 2013 at 10:49 PM, Nico Kadel-Garcia 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 change
> his
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 effe
On Tue, Sep 10, 2013 at 4:36 PM, Bob Archer 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 she
> -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 writ
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 ch
On Tue, Sep 10, 2013 at 6:22 AM, Nico Kadel-Garcia 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
> taken serio
> 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 pro
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.
http://www.
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 spac
Les Mikesell writes:
> On Mon, Sep 9, 2013 at 7:23 PM, Trent W. Buck wrote:
>> Ryan Schmidt 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 if the use
On Mon, Sep 9, 2013 at 7:23 PM, Trent W. Buck wrote:
> Ryan Schmidt 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 if the users have/need anything (emails, tic
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
> svnadm
Thorsten Schöning 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 noob attacking t
Ryan Schmidt 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 bad if Alice (who
should have
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 g
On Mon, Sep 9, 2013 at 8:03 AM, Grierson, David
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 subversion before and
did
eptember 2013 13:32
> To: Trent W. Buck
> Cc: Subversion
> Subject: Re: Breaking up a monolothic repository
>
> 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 pro
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 separate repos.
>
Why do you think an empty rev w
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 unneed
Geoff Field 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 start of develo
> From: Trent W. Buck
> Sent: Monday, 9 September 2013 12:17 PM
> Nico Kadel-Garcia 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 in
Nico Kadel-Garcia 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 software projects,
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 go
26 matches
Mail list logo
