You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2008/03/03 15:11:08 UTC
What to do about our repository (was: svn.collab.net is now running
1.5.0-alpha2)
There's been some discussion about the plan I put forth regarding our own
svn.collab.net repositories. If I had to guess, I'd say 90% of the mails
are folks explaining more precisely what it is I was planning to do and why
it carries the consequences I noted. The remaining few actually express
some opinion.
So where do we stand on this thing? Checking out working new copies is no
problem for me -- I've been branch-happy lately anyway, so I've been
checking out trees left and right. (And our tree isn't a very large one.)
But I can understand if folks would rather not go that route. If I'm doing
my counting right, so far it seems Justin is opposed, and while there have
been several folks *for* this change in IRC, they haven't really stated as
much in this thread.
As I see it, there are three different ways this can go:
1. We run 'svnadmin upgrade' and 'svn-populate-node-origins-index' and
'svnmerge-migrate-history.py' and 'fsfs-reshard.py' on
our repository. We get 1.5 features, HEAD svnmerge.py history migrated
and a populated node-origins index. Our merge tracking internals are
out of sync, but while it is inelegant, we don't think this will cause
a problem. If there are earlier proto-forms of merge tracking property
syntax in our tree that are not supported in alpha2, they may cause us
problems later (but I don't know if there are). Nobody needs to
checkout new working copies.
2. We dump/load our repository with no filtering and run
'svnmerge-migrate-history.py' on it. Same benefits as the previous
case except our node-origins cache is optimized, our merge tracking
internals are in sync, and we'll know if we have bogus proto-forms of
merge tracking property syntax because they might cause this whole
process to fail. Nobody needs to checkout new working copies.
3. We dump/load our repository with filtering and run
'svnmerge-migrate-history'. We get the benefits of the previous case
plus a cleanup of old mergeinfo that wasn't supposed to be there anyway
plus retroactive migration of our svnmerge history (instead of only
HEAD). Old proto-forms of merge tracking property syntax are no
problem because we've purged all that stuff. We all need new working
copies.
Thoughts? Opinions? Concerns?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: What to do about our repository
Posted by "C. Michael Pilato" <cm...@collab.net>.
David Glasser wrote:
> On Tue, Mar 4, 2008 at 10:02 AM, C. Michael Pilato <cm...@collab.net> wrote:
>> Arfrever Frehtes Taifersar Arahesis wrote:
>> > Do you also plan to introduce blocking of commits from pre-1.5 clients?
>> > http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.pre1.5clients
>>
>> Ooh! I hadn't thought about that, but it sure seems like smart idea.
>
> I'm concerned; won't we want to (a) *test* our supposed backwards
> compatibility and (b) allow committers who may not be on the bleeding
> edge yet (translators, say) to commit?
I don't have a strong opinion about this either way. We are tauting the
--record-only capabilities as a feature, so if someone does a merge with a
pre-1.5 client, we *should* be able to touch up the mergeinfo later, right?
If we wanted to toy with this some, we could block commits to places other
than trunk/ from pre-1.5 clients or something.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: What to do about our repository
Posted by David Glasser <gl...@davidglasser.net>.
On Tue, Mar 4, 2008 at 10:02 AM, C. Michael Pilato <cm...@collab.net> wrote:
> Arfrever Frehtes Taifersar Arahesis wrote:
> > Do you also plan to introduce blocking of commits from pre-1.5 clients?
> > http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.pre1.5clients
>
> Ooh! I hadn't thought about that, but it sure seems like smart idea.
I'm concerned; won't we want to (a) *test* our supposed backwards
compatibility and (b) allow committers who may not be on the bleeding
edge yet (translators, say) to commit?
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: What to do about our repository
Posted by "C. Michael Pilato" <cm...@collab.net>.
Arfrever Frehtes Taifersar Arahesis wrote:
> Do you also plan to introduce blocking of commits from pre-1.5 clients?
> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.pre1.5clients
Ooh! I hadn't thought about that, but it sure seems like smart idea.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: What to do about our repository (was: svn.collab.net is now running 1.5.0-alpha2)
Posted by Arfrever Frehtes Taifersar Arahesis <ar...@gmail.com>.
2008-03-03 16:11 C. Michael Pilato <cm...@collab.net> napisał(a):
> There's been some discussion about the plan I put forth regarding our own
> svn.collab.net repositories. If I had to guess, I'd say 90% of the mails
> are folks explaining more precisely what it is I was planning to do and why
> it carries the consequences I noted. The remaining few actually express
> some opinion.
>
> So where do we stand on this thing? Checking out working new copies is no
> problem for me -- I've been branch-happy lately anyway, so I've been
> checking out trees left and right. (And our tree isn't a very large one.)
> But I can understand if folks would rather not go that route. If I'm doing
> my counting right, so far it seems Justin is opposed, and while there have
> been several folks *for* this change in IRC, they haven't really stated as
> much in this thread.
>
> As I see it, there are three different ways this can go:
>
> 1. We run 'svnadmin upgrade' and 'svn-populate-node-origins-index' and
> 'svnmerge-migrate-history.py' and 'fsfs-reshard.py' on
> our repository. We get 1.5 features, HEAD svnmerge.py history migrated
> and a populated node-origins index. Our merge tracking internals are
> out of sync, but while it is inelegant, we don't think this will cause
> a problem. If there are earlier proto-forms of merge tracking property
> syntax in our tree that are not supported in alpha2, they may cause us
> problems later (but I don't know if there are). Nobody needs to
> checkout new working copies.
>
> 2. We dump/load our repository with no filtering and run
> 'svnmerge-migrate-history.py' on it. Same benefits as the previous
> case except our node-origins cache is optimized, our merge tracking
> internals are in sync, and we'll know if we have bogus proto-forms of
> merge tracking property syntax because they might cause this whole
> process to fail. Nobody needs to checkout new working copies.
>
> 3. We dump/load our repository with filtering and run
> 'svnmerge-migrate-history'. We get the benefits of the previous case
> plus a cleanup of old mergeinfo that wasn't supposed to be there anyway
> plus retroactive migration of our svnmerge history (instead of only
> HEAD). Old proto-forms of merge tracking property syntax are no
> problem because we've purged all that stuff. We all need new working
> copies.
>
> Thoughts? Opinions? Concerns?
Do you also plan to introduce blocking of commits from pre-1.5 clients?
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.pre1.5clients
Re: What to do about our repository
Posted by Karl Fogel <kf...@red-bean.com>.
"Ph. Marek" <ph...@bmlv.gv.at> writes:
> How about changing the URL a bit, so that people using the old repository get
> an additional file "README-IMPORTANT-REPOSURL-CHANGED" or something like that
> on the next update?
Ugh, no! :-) Some pages link directly into our repository, there's no
way we'd ever update them all (many don't belong to us).
The URL should stay stable.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: What to do about our repository (was: svn.collab.net is now running 1.5.0-alpha2)
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Dienstag, 4. März 2008, Erik Huelsmann wrote:
> On 3/4/08, Ben Collins-Sussman <su...@red-bean.com> wrote:
> > Honestly, I'd like to see #3. I really don't mind spending 3 minutes
> > checking out a working copy. I'm really curious to see what the
> > 'ideal' conversion looks like, complete with retroactive
> > merge-history. It tickles me pink!
>
> +1. I see little harm in a new checkout.
How about changing the URL a bit, so that people using the old repository get
an additional file "README-IMPORTANT-REPOSURL-CHANGED" or something like that
on the next update?
Maybe a rename "trunk" to "trunk-1.5" would suffice ... although that's not
very aesthetic.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: What to do about our repository (was: svn.collab.net is now running 1.5.0-alpha2)
Posted by Dongsheng Song <do...@gmail.com>.
agree.
2008/3/4, Ben Collins-Sussman <su...@red-bean.com>:
> Honestly, I'd like to see #3. I really don't mind spending 3 minutes
> checking out a working copy. I'm really curious to see what the
> 'ideal' conversion looks like, complete with retroactive
> merge-history. It tickles me pink!
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: What to do about our repository (was: svn.collab.net is now running 1.5.0-alpha2)
Posted by Arfrever Frehtes Taifersar Arahesis <ar...@gmail.com>.
2008-03-04 09:48 Erik Huelsmann <eh...@gmail.com> napisał(a):
> On 3/4/08, Ben Collins-Sussman <su...@red-bean.com> wrote:
> > Honestly, I'd like to see #3. I really don't mind spending 3 minutes
> > checking out a working copy. I'm really curious to see what the
> > 'ideal' conversion looks like, complete with retroactive
> > merge-history. It tickles me pink!
>
>
> +1. I see little harm in a new checkout.
+1
Re: What to do about our repository (was: svn.collab.net is now running 1.5.0-alpha2)
Posted by Erik Huelsmann <eh...@gmail.com>.
On 3/4/08, Ben Collins-Sussman <su...@red-bean.com> wrote:
> Honestly, I'd like to see #3. I really don't mind spending 3 minutes
> checking out a working copy. I'm really curious to see what the
> 'ideal' conversion looks like, complete with retroactive
> merge-history. It tickles me pink!
+1. I see little harm in a new checkout.
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: What to do about our repository (was: svn.collab.net is now running 1.5.0-alpha2)
Posted by Ben Collins-Sussman <su...@red-bean.com>.
Honestly, I'd like to see #3. I really don't mind spending 3 minutes
checking out a working copy. I'm really curious to see what the
'ideal' conversion looks like, complete with retroactive
merge-history. It tickles me pink!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: What to do about our repository (was: svn.collab.net is now running 1.5.0-alpha2)
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Mar 3, 2008 at 10:11 AM, C. Michael Pilato <cm...@collab.net> wrote:
> 2. We dump/load our repository with no filtering and run
> 'svnmerge-migrate-history.py' on it. Same benefits as the previous
> case except our node-origins cache is optimized, our merge tracking
> internals are in sync, and we'll know if we have bogus proto-forms of
> merge tracking property syntax because they might cause this whole
> process to fail. Nobody needs to checkout new working copies.
I guess this is my vote, #2. There will be other people with
mergeinfo props in their repository and this will help us learn if
there are things to fix when this happens. Setting aside the issue of
bogus props, either #1 or 2 are closest to what our users need to do,
so again it will help identify anything about the process that does
not work right or needs to be better.
I could even see us doing #1 for a few weeks and then doing #2
(without needing to re-run the svnmerge-migrate script the second
time.
Finally, we do not have a ton of branches with work going on that
would pick up some great benefit from being fancier. We are probably
better of staying close to what we are telling our users to do with
their repositories.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: What to do about our repository (was: svn.collab.net is now running 1.5.0-alpha2)
Posted by Troy Curtis Jr <tr...@gmail.com>.
On Mon, Mar 3, 2008 at 7:12 PM, Justin Erenkrantz <ju...@erenkrantz.com>
wrote:
> On Mon, Mar 3, 2008 at 7:11 AM, C. Michael Pilato <cm...@collab.net>
> wrote:
> > Thoughts? Opinions? Concerns?
>
> (Vote, not veto)
>
> +1 to either #1 or #2. Your call as to which is best.
>
> -1 to #3.
>
> My $.03. =) -- justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
I'm no regular Subversion developer, but I do use subversion a lot and a
MUCH larger code base at work. Even there checking out and doing a clean
compile is no big deal. It really surprises me you are so against running a
'svn co' command, especially since it seems the repo will be much more
consistent and almost appear as though you've been using 1.5 all along.
Really seems like the most obvious choice. Do you have a bazillion working
copies and so don't want to re-check a whole load of them? Just curious.
Troy
--
"Beware of spyware. If you can, use the Firefox browser." - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)
Re: What to do about our repository (was: svn.collab.net is now running 1.5.0-alpha2)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Mon, Mar 3, 2008 at 7:11 AM, C. Michael Pilato <cm...@collab.net> wrote:
> Thoughts? Opinions? Concerns?
(Vote, not veto)
+1 to either #1 or #2. Your call as to which is best.
-1 to #3.
My $.03. =) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: What to do about our repository
Posted by "C. Michael Pilato" <cm...@collab.net>.
Well, it looks like of the folks that voiced opinions, this is falling
toward option #3, so that's the route I'm going to take. I will tweak UUIDs
to be different, and I will *not* (at this time, anyway) install hooks that
prevent 1.4 clients from committing.
I'll transmit a followup mail when this is all done.
C. Michael Pilato wrote:
> There's been some discussion about the plan I put forth regarding our own
> svn.collab.net repositories. If I had to guess, I'd say 90% of the mails
> are folks explaining more precisely what it is I was planning to do and
> why it carries the consequences I noted. The remaining few actually
> express some opinion.
>
> So where do we stand on this thing? Checking out working new copies is
> no problem for me -- I've been branch-happy lately anyway, so I've been
> checking out trees left and right. (And our tree isn't a very large
> one.) But I can understand if folks would rather not go that route. If
> I'm doing my counting right, so far it seems Justin is opposed, and while
> there have been several folks *for* this change in IRC, they haven't
> really stated as much in this thread.
>
> As I see it, there are three different ways this can go:
>
> 1. We run 'svnadmin upgrade' and 'svn-populate-node-origins-index' and
> 'svnmerge-migrate-history.py' and 'fsfs-reshard.py' on our repository.
> We get 1.5 features, HEAD svnmerge.py history migrated and a populated
> node-origins index. Our merge tracking internals are out of sync, but
> while it is inelegant, we don't think this will cause a problem. If
> there are earlier proto-forms of merge tracking property syntax in our
> tree that are not supported in alpha2, they may cause us problems later
> (but I don't know if there are). Nobody needs to checkout new working
> copies.
>
> 2. We dump/load our repository with no filtering and run
> 'svnmerge-migrate-history.py' on it. Same benefits as the previous case
> except our node-origins cache is optimized, our merge tracking internals
> are in sync, and we'll know if we have bogus proto-forms of merge
> tracking property syntax because they might cause this whole process to
> fail. Nobody needs to checkout new working copies.
>
> 3. We dump/load our repository with filtering and run
> 'svnmerge-migrate-history'. We get the benefits of the previous case
> plus a cleanup of old mergeinfo that wasn't supposed to be there anyway
> plus retroactive migration of our svnmerge history (instead of only
> HEAD). Old proto-forms of merge tracking property syntax are no problem
> because we've purged all that stuff. We all need new working copies.
>
> Thoughts? Opinions? Concerns?
>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: What to do about our repository
Posted by Karl Fogel <kf...@red-bean.com>.
"C. Michael Pilato" <cm...@collab.net> writes:
> Thoughts? Opinions? Concerns?
All I ask is that if we require people to re-check-out their working
copies, that we change the repository UUID so there is no ambiguity
about the matter.
*** CLARIFICATION ***: People reading this thread might think we're
talking about every repository and working copy in the world. We're
not. This is about a special-case treatment of Subversion's *own*
repository, and is not, repeat *not*, going to be a required procedure
for other repositories and working copies. You will be able to
upgrade to Subversion 1.5 in the usual easy way, without requiring a
re-check-out of all your project's working copies.
Although Mike's original post was perfectly clear on this point, I'm
reiterating it here because my reply doesn't quote that part of his
mail, and I don't want to see Slashdot porn later today about
Subversion invalidating all working copies or something :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org