[arch-dev-public] Implementing package branches for the svntogit repos
Hi, The past few days I've been testing a new way to maintain the svntogit repositories [1]. The main change is keeping a separate branch for each package, in addition to the master branch which contains all packages. Currently, the log pages load very slow; waiting over a minute is not uncommon. If we switch to the new script, we can then specify the package branch we want and everything should load very quickly. :) Some relevant links: New script and log file after running for a couple of days: http://pkgbuild.com/~foutrelis/svntogit/ (The first run had to update a week's worth of packages. :p) Test repositories (click the 'refs' tab to get a list of all package branches): - http://pkgbuild.com/git/packages.git/ - http://pkgbuild.com/git/community.git/ What do you guys think? If there are no objections, I could do the switch (I'd need access to svntogit's $HOME on gerolde). [1] http://projects.archlinux.org/svntogit/
On Wed, Jul 20, 2011 at 2:15 AM, Evangelos Foutras
Hi,
The past few days I've been testing a new way to maintain the svntogit repositories [1]. The main change is keeping a separate branch for each package, in addition to the master branch which contains all packages.
Currently, the log pages load very slow; waiting over a minute is not uncommon. If we switch to the new script, we can then specify the package branch we want and everything should load very quickly. :)
Some relevant links:
New script and log file after running for a couple of days: http://pkgbuild.com/~foutrelis/svntogit/ (The first run had to update a week's worth of packages. :p)
Test repositories (click the 'refs' tab to get a list of all package branches):
- http://pkgbuild.com/git/packages.git/ - http://pkgbuild.com/git/community.git/
What do you guys think? If there are no objections, I could do the switch (I'd need access to svntogit's $HOME on gerolde).
This is definitely a ton faster, so thanks for researching and putting something together here. My only thought is it is hard to capture commits across multiple packages this way, or get an overall history but still drill down into the package level without hitting the problem we had before. Yes, I see master is still present there, but doing any browsing on that history is right where we were before. Do you have the script available you used to do this? I would like to at least try my "rewrite into subdirctories" hack as it would still enable commits to be on multiple packages, and using your script as a start point would be great. -Dan
On 21 July 2011 22:55, Dan McGee
My only thought is it is hard to capture commits across multiple packages this way, or get an overall history but still drill down into the package level without hitting the problem we had before. Yes, I see master is still present there, but doing any browsing on that history is right where we were before.
While it's a valid concern, I've never needed to do that. My goal here is to be able to quickly see what changed in a package. I frequently follow the "SVN Entries (trunk)" link on new packages and it was frustrating to wait a minute to get a log.
Do you have the script available you used to do this? I would like to at least try my "rewrite into subdirctories" hack as it would still enable commits to be on multiple packages, and using your script as a start point would be great.
If you come up with a relatively straightforward way to implement it, sticking packages into subdirectories could be preferable. Using branches, however, gives us constant lookup/traversal time; I'm guessing the bigger the subdirectory, the more time it'd take to get the history of a package within (still pretty fast though). You can get the script from http://pkgbuild.com/~foutrelis/svntogit/. Thanks for the feedback.
participants (2)
-
Dan McGee
-
Evangelos Foutras