so here is a (read-only) version of what the subversion repository will look-like right after the migration on thursday:
http://svn.puredata.info/svnroot/pure-data/
once the migration has finished, i would like to reorganize the /branches and /tags directories, so that they become navigable (or is it navigatable?), by creating subdirectories "pd", "pd-extended", "externals" and moving things around (e.g. "devel_0_35" should go into "devel/0_35".
i guess i will also delete /trunk/CVSROOT and /trunk/htdocs
mfg,.asdr IOhannes
On Feb 5, 2008, at 2:39 PM, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
i guess i will also delete /trunk/CVSROOT and /trunk/htdocs
the former being a leftover from CVS.
Fine by me.
the latter being unused since more than 3 years.
For the sake of history, I think we should keep this.
.hc
fgmasdr. IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
Hans-Christoph Steiner wrote:
On Feb 5, 2008, at 2:39 PM, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
i guess i will also delete /trunk/CVSROOT and /trunk/htdocs
the former being a leftover from CVS.
Fine by me.
the latter being unused since more than 3 years.
For the sake of history, I think we should keep this.
for the sake of history we have a revision control system! i am talking about issuing an "svn rm trunk/htdocs", which means that the directory is removed and the revision number is increased by one. whenever you do feel the urge to look at the htdocs, just issue a "svn update -r 9164", or if you prefer "svn update -r {2003-04-01}"
fmas.dr IOhannes
On Feb 6, 2008, at 4:54 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
On Feb 5, 2008, at 2:39 PM, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
i guess i will also delete /trunk/CVSROOT and /trunk/htdocs
the former being a leftover from CVS.
Fine by me.
the latter being unused since more than 3 years.
For the sake of history, I think we should keep this.
for the sake of history we have a revision control system! i am talking about issuing an "svn rm trunk/htdocs", which means that the directory is removed and the revision number is increased by one. whenever you do feel the urge to look at the htdocs, just issue a "svn update -r 9164", or if you prefer "svn update -r {2003-04-01}"
Thanks for the clarification of "delete". Fine by me.
.hc
------------------------------------------------------------------------ ----
If you are not part of the solution, you are part of the problem.
On 5 Feb 2008, at 19:04, IOhannes m zmoelnig wrote:
so here is a (read-only) version of what the subversion repository will look-like right after the migration on thursday:
wohoo!
once the migration has finished, i would like to reorganize the /branches and /tags directories, so that they become navigable (or is it navigatable?), by creating subdirectories "pd", "pd-extended", "externals" and moving things around (e.g. "devel_0_35" should go into "devel/0_35".
there is a bizarre amount of branches in there, ain't there!
can't wait...
d
David Plans Casal wrote:
can't wait...
i just noticed that we have to wait a bit longer:
for once, uploading the svn-repository to sourceforge takes forever, as right now i cannot get more than 20kB/s, and the (zipped) svndump is more than 200MB large; however i will probably try to upload the svndatabase directly (which totals to 80MB zipped) and convert it to an svndumpfile on the sf-shell) i guess this could be sped up even more with an rsync.
second, quoting the sourceforge docs: "The migration will be finished within 24 hours. It could be finished in as soon as an hour or two, depending on the size of your CVS repository and the number of projects queued for migration in front of yours. Returning to the page will display whether it completed, failed or is still in queue."
i am pretty sure, that an 880MB dumpfile (uncompressed) qualifies as "large", and thus it might take all the 24hours.
so expect the svn repository to be online on friday afternoon.
fgmadr. IOhannes
On Wed, 6 Feb 2008, IOhannes m zmoelnig wrote:
for once, uploading the svn-repository to sourceforge takes forever, as right now i cannot get more than 20kB/s,
Do you think it has to do with your connection or SF's connection?
and the (zipped) svndump is more than 200MB large
How do I get a CVS or SVN dump myself? I like backups that I really have... I'd like to trust SF.NET but then see what happened when people trusted MP3.COM...
If mere developers are prevented from downloading a repository backup, then could you please put a copy of it somewhere, that I could download...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Mathieu Bouchard wrote:
On Wed, 6 Feb 2008, IOhannes m zmoelnig wrote:
for once, uploading the svn-repository to sourceforge takes forever, as right now i cannot get more than 20kB/s,
Do you think it has to do with your connection or SF's connection?
the latter. please note that this is really not directly related to how fast subversion will be once it is up and running.
and the (zipped) svndump is more than 200MB large
How do I get a CVS or SVN dump myself? I like backups that I really have... I'd like to trust SF.NET but then see what happened when people trusted MP3.COM...
If mere developers are prevented from downloading a repository backup, then could you please put a copy of it somewhere, that I could download...
everybody can download the entire repository via rsync: a quick google for "sourceforge svn" revealed as the first hit: http://alexandria.wiki.sourceforge.net/Subversion+-+Version+Control+for+Sour...
so you can get the filesystem backend of the repository, and due to rsyncs nature, you can get themincrementally. the issues i am experiencing are only with moving one _huge_ data file around through a long thin wire.
fgmadr. IOhannes
On 7 Feb 2008, at 01:57, Mathieu Bouchard wrote:
On Wed, 6 Feb 2008, IOhannes m zmoelnig wrote:
for once, uploading the svn-repository to sourceforge takes forever, as right now i cannot get more than 20kB/s,
Do you think it has to do with your connection or SF's connection?
and the (zipped) svndump is more than 200MB large
How do I get a CVS or SVN dump myself? I like backups that I really have... I'd like to trust SF.NET but then see what happened when people trusted MP3.COM...
You can (as of SVN 1.4) just setup an svnsync service (effectively a local mirror), then localy do 'svnadmin dump' and there's your backup.
David
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada_______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Tue, 5 Feb 2008, IOhannes m zmoelnig wrote:
so here is a (read-only) version of what the subversion repository will look-like right after the migration on thursday: http://svn.puredata.info/svnroot/pure-data/
Is there a way to turn a CVS checkout into a SVN checkout? I could just checkout http://svn.puredata.info/svnroot/pure-data/branches/desiredata/ but I have zillions of private files and folders mixed in with the CVS checkout... is there an easy way to move them around from a CVS checkout to a SVN checkout?
Also, are we going to get a mail on pd-dev just before the migration starts, and another mail just before it ends? because, I suppose that we aren't supposed to commit during that time?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Is there a way to turn a CVS checkout into a SVN checkout? I could just checkout http://svn.puredata.info/svnroot/pure-data/branches/desiredata/ but I have zillions of private files and folders mixed in with the CVS checkout... is there an easy way to move them around from a CVS checkout to a SVN checkout?
SVN has the "svn ls" -R command that only lists what the client knows about (or conversely "svn status | grep ?" shows what it doesn't know about); perhaps there is something similar for CVS? That plus some shell-fu would probably do the trick.. (alternately you could just look for "CVS/" folders?)
Mathieu Bouchard wrote:
Also, are we going to get a mail on pd-dev just before the migration starts, and another mail just before it ends? because, I suppose that we aren't supposed to commit during that time?
i will start the migration to subversion NOW.
please do not commit anything to CVS any more, until i sent an email that migration has finished.
step-by-step:
#1 turn off all CVS r/w. #2 get a copy of the CVS-repository (rsync) #3 do the migration (cvs2svn) #4 upload the svn-db to sourceforge (rsync) #5 convert the svn-db into an svndump-file #6 initiate the import of the svndump #7 pray that all goes well (and wait) #8 keep waiting #9 once the import was successfull, i will send an email to this list that you can now switch.
mfga.sdr IOhannes
Yeeee haw! Thanks for doing this!
Then I'll have to figure out the build farm...
.hc
On Feb 7, 2008, at 4:18 AM, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
Also, are we going to get a mail on pd-dev just before the migration starts, and another mail just before it ends? because, I suppose that we aren't supposed to commit during that time?
i will start the migration to subversion NOW.
please do not commit anything to CVS any more, until i sent an email that migration has finished.
step-by-step:
#1 turn off all CVS r/w. #2 get a copy of the CVS-repository (rsync) #3 do the migration (cvs2svn) #4 upload the svn-db to sourceforge (rsync) #5 convert the svn-db into an svndump-file #6 initiate the import of the svndump #7 pray that all goes well (and wait) #8 keep waiting #9 once the import was successfull, i will send an email to this list that you can now switch.
mfga.sdr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
kill your television