You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Roland Dreier <ro...@digitalvampire.org> on 2004/01/07 19:55:20 UTC
Fix to cvs2svn.py -p option for 1.0
I think that my tiny patch to cvs2svn.py (which moves the
initialization of start_pass to the correct place in the script)
should probably be committed to the 1.0-stabilization branch. (It was
committed to trunk as revision 8166)
Without the patch, the -p option of cvs2svn.py is completely broken,
and the patch is "low risk" and "totally obvious" (famous last words,
I know, but in this case I think it's true).
Thanks,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Fix to cvs2svn.py -p option for 1.0
Posted by Ben Reser <be...@reser.org>.
On Thu, Jan 08, 2004 at 12:12:01PM -0600, kfogel@collab.net wrote:
> It would be a terrible mistake to tie the release of Subversion 1.0 to
> the state of cvs2svn. If the rest of Subversion is ready, and cvs2svn
> is not, then we shouldn't wait for cvs2svn. Why should the people who
> want to start using Subversion without legacy data be punished,
> especially since it wouldn't bring Subversion to those who *do* have
> legacy data any sooner? It doesn't make sense.
Well I wouldn't delay 1.0 for cvs2svn. But I wouldn't not include a
cvs2svn.
> We can ship with what we have, include a clear warning that cvs2svn is
> not done, and pointers to where to track its progress. Or, we can
> ship without it entirely. But delaying Subversion's release for an
> essentially arbitrary amount of time would be like saying "We'll camp
> here for the night, oh and by the way construct a nuclear reactor from
> spare parts in the morning, then make for summit in the afternoon."
> Yeah, right.
Oh I don't anyone is advocating that. But you better look out for the
US military when you start constructing that nuclear reactor. They
don't seem to like that very much. :)
Seriously, though I think we should ship cvs2svn, ship the best version
available at the time, and like you said provide documentation that
points to a place to look for updated versions of it.
That makes perfect sense to me.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Fix to cvs2svn.py -p option for 1.0
Posted by kf...@collab.net.
Eric Gillespie <ep...@pretzelnet.org> writes:
> I'm sure the previous posters will correct me if i misrepresent
> them, but that's exactly what i see them advocating. I don't
> want to see Subversion 1.0 held up waiting for cvs2svn, but i
> also don't want it to ship with an old cvs2svn. Subversion 1.0
> should include the best cvs2svn we have, from the trunk.
Oh. Let's see what state it's in then, yes. We'll want to ship with
either the latest trunk cvs2svn, or none at all, agree.
> This seems to be a recurring trend in these 1.0 discussions :).
> Subversion ships with some side projects that are not maintained
> on the same schedule, and sometimes not even by the same people.
> Subversion itself has a certain set of requirements for its 1.0
> release, and holding the bindings or cvs2svn to these
> requirements is not constructive.
Agreed.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Fix to cvs2svn.py -p option for 1.0
Posted by Eric Gillespie <ep...@pretzelnet.org>.
kfogel@collab.net writes:
> It would be a terrible mistake to tie the release of Subversion
> 1.0 to the state of cvs2svn. If the rest of Subversion is
> ready, and cvs2svn is not, then we shouldn't wait for cvs2svn.
I couldn't agree more. But, i don't think that's what the
previous posters are talking about.
> We can ship with what we have, include a clear warning that
> cvs2svn is not done, and pointers to where to track its
> progress.
I'm sure the previous posters will correct me if i misrepresent
them, but that's exactly what i see them advocating. I don't
want to see Subversion 1.0 held up waiting for cvs2svn, but i
also don't want it to ship with an old cvs2svn. Subversion 1.0
should include the best cvs2svn we have, from the trunk.
This seems to be a recurring trend in these 1.0 discussions :).
Subversion ships with some side projects that are not maintained
on the same schedule, and sometimes not even by the same people.
Subversion itself has a certain set of requirements for its 1.0
release, and holding the bindings or cvs2svn to these
requirements is not constructive.
I really want to see Subversion 1.0 ship with the best cvs2svn
and bindings that we have available.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Fix to cvs2svn.py -p option for 1.0
Posted by kf...@collab.net.
John Szakmeister <jo...@szakmeister.net> writes:
> > For 1.0 I think we need a CVS migration tool included. I also think it
> > should be the best tool we have available. My concern will be if people
> > don't see the tool included they won't realize it exists. Plus I don't
> > think I would search for cvs2svn if I was looking for a conversion tool.
>
> I completely agree. I don't see a better way to win over the hearts of CVS
> users, than to provide them with a great tool (Subversion), along with a
> mechanism to get their repositories converted.
It would be a terrible mistake to tie the release of Subversion 1.0 to
the state of cvs2svn. If the rest of Subversion is ready, and cvs2svn
is not, then we shouldn't wait for cvs2svn. Why should the people who
want to start using Subversion without legacy data be punished,
especially since it wouldn't bring Subversion to those who *do* have
legacy data any sooner? It doesn't make sense.
We can ship with what we have, include a clear warning that cvs2svn is
not done, and pointers to where to track its progress. Or, we can
ship without it entirely. But delaying Subversion's release for an
essentially arbitrary amount of time would be like saying "We'll camp
here for the night, oh and by the way construct a nuclear reactor from
spare parts in the morning, then make for summit in the afternoon."
Yeah, right.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Fix to cvs2svn.py -p option for 1.0
Posted by John Szakmeister <jo...@szakmeister.net>.
On Thursday 08 January 2004 02:35, Ben Reser wrote:
> On Wed, Jan 07, 2004 at 11:45:14PM -0600, kfogel@collab.net wrote:
> > I'm thinking that maybe we should break it out into a separate
> > project, so its schedule doesn't have to get confused with SVN's
> > schedule. Not sure yet, though. Thoughts welcome!
>
> For 1.0 I think we need a CVS migration tool included. I also think it
> should be the best tool we have available. My concern will be if people
> don't see the tool included they won't realize it exists. Plus I don't
> think I would search for cvs2svn if I was looking for a conversion tool.
I completely agree. I don't see a better way to win over the hearts of CVS
users, than to provide them with a great tool (Subversion), along with a
mechanism to get their repositories converted.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Fix to cvs2svn.py -p option for 1.0
Posted by Ben Reser <be...@reser.org>.
On Wed, Jan 07, 2004 at 11:45:14PM -0600, kfogel@collab.net wrote:
> I'm thinking that maybe we should break it out into a separate
> project, so its schedule doesn't have to get confused with SVN's
> schedule. Not sure yet, though. Thoughts welcome!
For 1.0 I think we need a CVS migration tool included. I also think it
should be the best tool we have available. My concern will be if people
don't see the tool included they won't realize it exists. Plus I don't
think I would search for cvs2svn if I was looking for a conversion tool.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Fix to cvs2svn.py -p option for 1.0
Posted by kf...@collab.net.
"Max Bowsher" <ma...@ukf.net> writes:
> I guess its time to sort out a consensus about cvs2svn and 1.0.
>
> If you look at the issue tracker, you will be able to see that there are
> important defects to be resolved before cvs2svn can be considered 1.0.
The "cvs2svn-1.0" milestone has always referred to a separate 1.0 of
cvs2svn's, by the way, not to SVN 1.0.
> cvs2svn simply isn't close enough to 1.0 for the whole STATUS/3
> votes/stabilization thing to be workable. I believe most, if not all,
> cvs2svn changes on the trunk will need application to the branch - either
> because they are small, or because they are complex but fix important bugs.
There is no way the necessary changes to cvs2svn could get into SVN
1.0 via the current approval process.
> In other words, it will likely be appropriate to copy cvs2svn from the trunk
> to the 1.0 branch.
Something like that, yes.
Mike Pilato have some time allocated to work on cvs2svn in the next
few weeks (while SVN 1.0 is stabilizing & being tested). Let's see
how that goes, then decide what to do.
I'm thinking that maybe we should break it out into a separate
project, so its schedule doesn't have to get confused with SVN's
schedule. Not sure yet, though. Thoughts welcome!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Fix to cvs2svn.py -p option for 1.0
Posted by Max Bowsher <ma...@ukf.net>.
Roland Dreier wrote:
> I think that my tiny patch to cvs2svn.py (which moves the
> initialization of start_pass to the correct place in the script)
> should probably be committed to the 1.0-stabilization branch. (It was
> committed to trunk as revision 8166)
>
> Without the patch, the -p option of cvs2svn.py is completely broken,
> and the patch is "low risk" and "totally obvious" (famous last words,
> I know, but in this case I think it's true).
I guess its time to sort out a consensus about cvs2svn and 1.0.
If you look at the issue tracker, you will be able to see that there are
important defects to be resolved before cvs2svn can be considered 1.0.
cvs2svn simply isn't close enough to 1.0 for the whole STATUS/3
votes/stabilization thing to be workable. I believe most, if not all,
cvs2svn changes on the trunk will need application to the branch - either
because they are small, or because they are complex but fix important bugs.
In other words, it will likely be appropriate to copy cvs2svn from the trunk
to the 1.0 branch.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org