Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 25 Jul 2014, 04:24
All times are UTC - 4
 Forum index » Advanced Topics » Cutting edge
Putting Unleashed under a Revisioning System
Moderators: Flash, Ian, JohnMurga
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
Page 1 of 4 Posts_count   Goto page: 1, 2, 3, 4 Next
Author Message
Pizzasgood


Joined: 04 May 2005
Posts: 6270
Location: Knoxville, TN, USA

PostPosted: Sun 02 Nov 2008, 23:27    Post_subject:  Putting Unleashed under a Revisioning System
Sub_title: Thoughts?
 

This has been discussed a little in different spots, but it was always an off topic side discussion. I'm very serious about setting something like this up, so I'm starting a real thread for it.

Reasoning for putting Unleashed in a revisioning system like Subversion:
  • It allows the developers to contribute directly.
  • Direct contribution may make certain things easier, such as going through and properly localizing Puppy, and keeping it that way. (Obviously we'd have to watch the devs and yell at them when they don't localize their code).
  • Removing the middle man removes opportunity for accidental errors.
  • Removing the middle man lifts a lot of burden from the "coordinator", assuming we keep using coordinators. He doesn't have to manually add in every little change. If we stick with the coordinator approach, he would still make the decisions and stuff, just not have to implement everything himself. I'm sure WhoDo understands what I'm saying here Wink
  • Changes are recorded automatically. If you notice that something has broken in the latest release of Puppy, you can look up exactly what has changed in each file.
  • By allowing anonymous reading, people can see what has changed on a day to day basis, and who changed it. They can test new features immediately, or simply satisfy their curiosity. If a bug fix is implemented, it is available immediately.
  • Collisions are much less likely. A collision is when two people are working on the same file, and one submits their modified one after the other has already submitted his, causing the other one to be overwritten. It is difficult to keep track of that sort of thing when middle-men are involved. SVN will automatically notify you if the file has changed while you worked on it, and it will help you to merge the changes together, often taking care of it automatically (like if you were working on the bottom of the file, and the other person modified the top).


This link explains some of what I was talking about with regard to collisions, and helps explain how SVN works:
http://svnbook.red-bean.com/en/1.5/svn.basic.html

There are several options for what software to use. I'm leaning toward SVN, because that seems the most straightforward. Git has some fancy features, but we don't really need them AFAIK.

So, I've been working on setting up my old computer to serve as a test server while we figure out the best layout and stuff. Then, Caneri is considering hosting us on one of his new servers if they prove to be stable.


Issues/questions:
1: I was going to get it all set up tonight and then start this thread for discussion, but I ran into a snag: Neither SVN nor Git can handle device files (like in /dev/). We could get around that by keeping those in an archive, and having a script to unarchive them and remove the archive before building Puppy. We probably need a script to go from the svn layout to a proper unleashed layout anyways, so that could just be part of it. There could be another one to go in reverse. I'm going to play with this next time I have free time.

Does anybody have a better idea? Or know of another software that handles these files?

2: How best to handle upgrades to new base-versions of Puppy (such as after a rebuild from t2)? I think that the simplest method would be to single out any packages with significant Puppy changes (like 0rootfs_skeleton) and handle them by doing an svn copy on the old version to the new version's name, then replace the files with the new version. That way the histories for the files that are kept (like the wizards) would be preserved. Things with almost no Puppy changes might be easier to just import, I dunno. I still haven't gotten around to fiddling with T2, as I've been so busy with school. What are your thoughts?

3: Unleashed is big. We will need to set up a method to download the actual packages and such for unleashed from the package server like we do now, and then extract them and move them into the proper layout for SVN. Then do the svn checkout over those files, using the --force option. Then we'd have to do an 'svn revert' to bring it up to date with the server (when it checked out the files, it considered any differences in the local files to be new, not old, so we'd need to use revert rather than update). Finally, we may need to run a script to get a list of all files under revision control, and then go through the tree and remove any that aren't. Otherwise if a file that existed when the package was made gets removed later, it will still hang around because SVN will ignore it. This doesn't cause any problems directly, but it could be confusing to the user, as he may not realize that the file isn't being used, or may think that the file belongs and re-add it, causing issues. All this stuff can be scripted of course, so that the user just has to run the script and it will take care of everything.

Maybe doing all that isn't necessary, but I think it might be more efficient than just checking out the entire system. I think a checkout would download a lot more small files, rather than the smaller number of package files. It depends on how SVN transfers its data I suppose. Anybody know which would be more efficient?

4: What file layout would be best? I suspect that it would be easiest to have the standard 'tags', 'branches', and 'trunk' directories at the top, then put the main line in 'trunk'. This way when doing a major upgrade of Puppy, it can be done in /branches, and when a release version is ready, the whole thing can be put into /tags with one command. This makes it seem like maybe branching a single package wouldn't work well, but SVN is very flexible. You can simply branch it to /branches/my_branched_package. SVN doesn't actually care if the layout of everything in /branches matches /trunk. When you finish, just remove it from /branches. Tagging packages would be more of an issue, but wouldn't really be necessary afaik. If the package reaches a good stable stopping point before the next version of Puppy is ready, just copy the package over to a new version number and keep going, leaving the packages.txt file pointed at the old stable version until the new one becomes stable. Every now and then we could prune out the old unused versions, just to make things cleaner. The wouldn't actually be removed though, since it's SVN, so if you need the old version you can just go back and get it.

I also think that the packages directory should be split out from the unleashed_core. For people who maintain a full local tree, it makes no real difference. But for people who just want to check out the unleashed_core so they can work on it don't want to have to do fancy commands to skip checking out all of the packages. So separating it into a packages directory containing all the packages and an unleashed_core directory for the core would correct this. They can be put back together easily when it's time for a build, or simply simlinked.

So the overall structure I'm envisioning would be like this:
Code:
bash-3.00# tree
.
|-- branches
|-- tags
`-- trunk
    |-- packages
    |   |-- 0rootfs_skeleton-4.02
    |   |-- pkitchensink-9.54
    |   `-- some_prog-0.24
    `-- unleashed_core
        |-- boot
        |-- isolinux-builds
        |-- kernel
        `-- packages -> ../packages
(obviously many files and directories have been omitted for clarity)

Any other thoughts? Problems? Better ideas?

5: How will something this large handle? That question is the main reason I'm setting up my test server. I want to experiment with it to see what kind of performance I get. I also want to simulate a large number of changes and see how fast the size grows. It's running on a 450MHz PIII, so it isn't the fastest machine in the world, but it's reasonable. If it performs well on this, it ought to be just find on Caneri's server, CPU wise.

Initial numbers: it looks like when you take a 996 MB unleashed tree and import it into SVN (minus the device files, which are probably insignificant), it only seems to use 269 MB. So it looks like it compresses stuff. That's good. I was expecting it to be 10% more than the original, but it's actually 75% less than the original.

6: Is using the svnserve program good enough (for now)? Does anybody think we really need to be using encryption to contribute? Does anybody think that they in particular will need an encrypted connection (oppressive laws or whatnot)? I do plan to work out a web frontend, but that's low on my priority list.



I have the test server running and most of the data loaded in. I need to get a little more done before I can make it public though, and I won't have time tonight. I have to go decide what classes to take next semester, which is harder than it sounds - have to make sure the schedules work out properly. Pain in the butt. Then if I don't get in and sign up immediately, a key class may be filled up and have broken the entire schedule. I think I'm in the very first group to sign up this year though, so hopefully that won't be an issue.


How many people are interested in playing with the test server? If you tell me now I can get you all usernames right away. Or should I just make a generic test user and post the password here? It is only a test server, so that's an option for now. Unless people start abusing my bandwidth. I'm on my campus's network, and the policy here is that hitting a GB a day more often than once a week or so is abusive.

Hopefully I'll be able to finish up on Tuesday. Nearly there now, but I'll probably spend all evening tomorrow doing homework.



So, discuss! Any deal-breaking problems I've overlooked? Any better options? Any suggestions? Speak boy, speak.

Good doggy Laughing


Oh, and to head off the "SVN has been tried before, didn't work" argument: No, it has not. Not like this, anyways. An SVN for Puppy-related programs is one thing. An SVN for the official Unleashed tree is quite another. Until now, Barry has done most of the work, and he did it himself. Now the Community is supposed to do the work. What better way than to simply allow the Community to do the work? As opposed to picking one person to shoulder the burden and try to put together everything that everybody is submitting to him? No. Let the devs develop, I say.

_________________
Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib

Back to top
View user's profile Send_private_message Visit_website 
cb88


Joined: 28 Jan 2007
Posts: 1169
Location: USA

PostPosted: Mon 03 Nov 2008, 01:41    Post_subject:  

is there some reason you are setting up a private svn? some inadequacy on sourceforges part?

there is the concern that the svn server could fail.... witch is an issue with private svn moreso than source forge

if you are worried about the size... i don't think even 500mb is an issue there are larger project on source forge... also unleashed isn't that big is it? the kernel should not be in svn... should it? or any binary package

_________________
Taking Puppy Linux to the limit of perfection. meanwhile try "puppy pfix=duct_tape" kernel parem eater.
X86: Sager NP6110 3630QM 16GB ram, Tyan Thunder 2 2x 300Mhz
Sun: SS2 , LX , SS5 , SS10 , SS20 ,Ultra 1, Ultra 10 , T2000
Mac: Platinum Plus, SE/30
Back to top
View user's profile Send_private_message Visit_website 
WhoDo


Joined: 11 Jul 2006
Posts: 4441
Location: Lake Macquarie NSW Australia

PostPosted: Mon 03 Nov 2008, 03:17    Post_subject: Re: Putting Unleashed under a Revisioning System
Sub_title: Thoughts?
 

Pizzasgood wrote:
[*]Removing the middle man lifts a lot of burden from the "coordinator", assuming we keep using coordinators. He doesn't have to manually add in every little change. If we stick with the coordinator approach, he would still make the decisions and stuff, just not have to implement everything himself. I'm sure WhoDo understands what I'm saying here Wink

WhoDo "understands", applauds, begs and pants in anticipation!
cb88 wrote:
if you are worried about the size... i don't think even 500mb is an issue there are larger project on source forge... also unleashed isn't that big is it?

Oh yes it is, cb88. In fact it is significantly bigger than that. Unleashed core for 4.1.1 is 51Mb but there is around 590Mb+ of packages in the basic Unleashed tree, and up to 1Gb for a comprehensive tree - maybe more if we have a significant boost in private development for Puppy. Keeping those up-to-date is a major task for any Puppy builder, and is one of the reasons why I stipulated that I wouldn't be spending time chasing package updates and bugs in 4.2 without some assistance from the community. PG's idea puts that in a framework that package developers don't have to PM/email the coordinator with every request to include a new or updated package in the tree.

It doesn't matter to me whether the repository exists on Sourceforge or some other private/public server. All that matters is that at any point in time I can capture a snapshot of the Unleashed tree to build a release, and I'm reasonably sure that the most up-to-date packages are in that snapshot. At the moment that involves package devs sending me updates via email or PM, or them uploading and me downloading updates from a shared FTP server to my Unleashed partition. The problems come when I'm not sure whether what is in that partition is the latest I've been provided or the latest available.

I'm not semi-retired like BarryK, and I have to make time for Puppy alongside my real job and my family life. Anything that makes it easier for me to contribute my bit to Puppy is a plus in my book. I'm too old and too set in my ways to risk a divorce for my hobby! Razz

_________________
Actions speak louder than words ... and they usually work when words don't!
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
Back to top
View user's profile Send_private_message 
HairyWill


Joined: 26 May 2006
Posts: 2949
Location: Southampton, UK

PostPosted: Mon 03 Nov 2008, 07:49    Post_subject:  

cb88 wrote:
is there some reason you are setting up a private svn? some inadequacy on sourceforges part?
My understanding was that sourceforge is unwilling to host entire distros on svn.

I would be interested in having at least read access for automated testing. I don't make changes that often so would be happy to submit changes to someone else if I didn't have write access.

_________________
Will
contribute: community website, screenshots, puplets, wiki, rss
Back to top
View user's profile Send_private_message 
raffy

Joined: 25 May 2005
Posts: 4759
Location: Manila

PostPosted: Mon 03 Nov 2008, 19:34    Post_subject: core  

Thanks, Pizzasgood.

A number of terms here refer to a filesystem and/or minimum size for Puppy, like "base version", "unleashed core", or "0rootfs_skeleton". We have user-oriented terms, too, like "onebone" (no X) and "barebone" (no big applications). These terms are relevant to the SVN with respect to limiting its scope for building a working base.

Someone (or a small group) will have to decide what constitutes a minimal Puppy build, from which larger builds can be based on. The build script itself may have to be changed. An illustrative question could be, "What if someone wanted to build a Puppy with a different GTK version, or would not use GTK?", or "Would 'building Puppy' be synonymous to 'using GTK', and if so, how would different GTK versions be handled?"

New PCs/netbooks require new drivers, and new kernels include new drivers and features. This adds complications to a build system. Forum member amigo describes one way out, which is to use a longtime supported kernel, like 2.6.16 c/o Adrian Bunk (which is now 2.6.27). (This is one of the questions in coming up with a basic build of Puppy.)

_________________
Puppy user since Oct 2004. Want FreeOffice? Get the sfs (English only).
Back to top
View user's profile Send_private_message 
Pizzasgood


Joined: 04 May 2005
Posts: 6270
Location: Knoxville, TN, USA

PostPosted: Mon 03 Nov 2008, 23:14    Post_subject:  

Quote:
is there some reason you are setting up a private svn? some inadequacy on sourceforges part?
I'm not sure if inadequacy is the right word, but yeah. I read their terms, and they basically don't like to host entire distros, though they will consider it if asked. But the main thing is their name - sourceforge. They are mainly a source place. I'm not talking about sources, I'm talking about the entire unleashed tree. This is the intermediate stage between compiling the binaries from the source files, and the iso itself. It's where everything is put together.

I'm not trying to make the SF account obsolete. Actually, I think the two repositories would cooperate. SF is where the development of applications for Puppy could happen. For example, I'm using it for my RetroVol program. If we decide to include that in Puppy someday, a binary unleashed package could be put together and imported into the Unleashed SVN.

WhoDo mentioned that he doesn't particularly care where this is set up. I agree. I don't think it would fly very well with SF though, and Caneri has offered to host us if those new servers work out. That would give the Puppy community much more control over the server than if we were hosted elsewhere. If it doesn't work out with Caneri, then it may be worth contacting SF and seeing if they'd make an exception for us. I think Google also hosts some open source projects? Maybe they'd be another place to inquire. Right now though, I'm more concerned with getting a test server working so we can figure out what we'll need. Then if we do have to look elsewhere, we'll at least have a pretty good idea of what to ask for.


Quote:
1: I was going to get it all set up tonight and then start this thread for discussion, but I ran into a snag: Neither SVN nor Git can handle device files (like in /dev/). We could get around that by keeping those in an archive, and having a script to unarchive them and remove the archive before building Puppy.
And, a good way to do this is to go into each package with device files (mainly 0rootfs_skel) and place them into a tar archive for that package, and then add some lines in that package's pinstall.sh script to extract them and remove the archive. Besides being a nice clean way to do it, it also means that in both the SVN and Unleashed tree's normal state, the device files would be in the archive. I think that's probably a good thing, because I've had some issues with device files becoming messed up when I moved them around too much. I think it was transferring them to my laptop via scp. This way they stay archived, so things can be moved around safely. It may be a slight annoyance to have to add new device files to the archive, but it's pretty rare that they ever need to be dealt with, so not a real issue.

Quote:
I would be interested in having at least read access for automated testing.
My thinking has always been to have anonymous read access. Maybe find a way to disable checking out the entire thing at once anonymously, IF bandwidth becomes a problem, but anybody should be able to check out any revision of any package any time, IMHO.




@raffy: I do agree that there is a lot we can do to improve the puppy creation process, especially with regard to further facilitating puppy derivatives. But I think that's a topic that is outside the scope of what I'm trying to do here. For example, I think that we should maintain at least one extra packages.txt file, for creating a small basic Puppy to use as a foundation for derivatives. But that doesn't impact the use of SVN at all. I also have ideas about modifying Unleashed to make it easier to work on a derivative long term, across multiple versions of Puppy. That would require some structural changes to Uneashed, but only slight changes to the SVN tree (mainly moving a couple directories around).

_________________
Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib

Back to top
View user's profile Send_private_message Visit_website 
disciple

Joined: 20 May 2006
Posts: 6425
Location: Auckland, New Zealand

PostPosted: Tue 04 Nov 2008, 00:36    Post_subject:  

SF seems to be painfully slow to browse anyway (at least around here). Will this be browseable (in a browser, rather than an SVN client)?
What exactly is/will be the connection between the unleashed SVN and the petget repository?
I'm thinking it will get quite a bit bigger, as it will include all the files for petget, and we will probably want to move from everyone posting .pets on the forum to actually making official .pets instead. Or will it not include everything?

_________________
DEATH TO SPREADSHEETS
- - -
Classic Puppy quotes
- - -
Beware the demented serfers!
Back to top
View user's profile Send_private_message 
Pizzasgood


Joined: 04 May 2005
Posts: 6270
Location: Knoxville, TN, USA

PostPosted: Tue 04 Nov 2008, 03:06    Post_subject:  

Browser-browsablility is a definite goal. Right now I'm focusing on just the basic server aspect though, since that's the part that really matters. My homework, need for sleep, and the shipment of LEGO gears and pneumatic pistons that just arrived limit my time somewhat. (Must exercise my willpower for a while and refuse to open that package until more important things are done.)

As for SVN vs PETget: SVN is the development area. When a stable version of Puppy is ready, it would be "tagged", which is basically just a way to mark that particular revision as being special and giving it a name. Then that revision would be used to build the .iso files, and the package directories would be compressed, turned into .pet packages, and uploaded to the normal file server.

Between versions of Puppy, one could checkout a package from the SVN to get the latest changes. It would come out extracted though, so to install it you'd have to either copy it into your filesystem manually, or turn the directory into a .pet package (easy, just tar czf package-1.2.3.tar.gz package-1.2.3; tgz2pet package-1.2.3.tar.gz) and install it that way. Or I believe you could have SVN generate diff files for the changes between the stable version and the current revision, then just apply those.


Quote:
I'm thinking it will get quite a bit bigger, as it will include all the files for petget, and we will probably want to move from everyone posting .pets on the forum to actually making official .pets instead. Or will it not include everything?
Hmmm.... I guess it depends on how we do the normal repositories. Currently, the SVN repo would hold all the "official" packages, and therefor so would the normal PETget repo. We definitely wouldn't want to start having everybody make pets that go into the SVN repo. That would make things too big. I think if we ever set up a larger more formal repository system, we'd probably need to modify the idea of the "official" pets. Rather than have a good number of stuff we never plan to use officially, we'd want to just keep the stuff we are using or considering using. When we finish and upload the isos, we'd also upload all the packages we used, along with any we considered using that have notable changes from the "stock" versions in the normal repository. They'd mainly be for people making derivatives, or to add in the "deleted scenes" that the devs didn't include. The package manager would mainly be oriented at what you could call the third-party repository, but at that point I think it would be more of a first or second party repo (can you have a second-party repo?) where the stuff has gone through some kind of quality control.
_________________
Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib


Edited_time_total
Back to top
View user's profile Send_private_message Visit_website 
Lobster
Official Crustacean


Joined: 04 May 2005
Posts: 15117
Location: Paradox Realm

PostPosted: Tue 04 Nov 2008, 03:15    Post_subject:  

Quote:
I think Google also hosts some open source projects?


http://code.google.com/hosting/

_________________
Puppy WIKI
Back to top
View user's profile Send_private_message Visit_website 
HairyWill


Joined: 26 May 2006
Posts: 2949
Location: Southampton, UK

PostPosted: Tue 04 Nov 2008, 04:05    Post_subject:  

Quote:
I think Google also hosts some open source projects?

google ToS wrote:
Users residing in countries on the United States Office of Foreign Assets Control sanction list, including Cuba, Iran, Libya, North Korea, Sudan and Syria, may not post or access Content available through the Google Code website.
Do the US government rules apply to all software or just that related to encryption? Is the onus on the website owner to prevent such access?
_________________
Will
contribute: community website, screenshots, puplets, wiki, rss
Back to top
View user's profile Send_private_message 
cb88


Joined: 28 Jan 2007
Posts: 1169
Location: USA

PostPosted: Tue 04 Nov 2008, 10:29    Post_subject:  

the only reason unleashed is so huge is that it includes the kernel... that is a binary package and should not be included

unleashed should consist of ONLY the build scripts as those chance little between versions

kernels should not be in unleashed

_________________
Taking Puppy Linux to the limit of perfection. meanwhile try "puppy pfix=duct_tape" kernel parem eater.
X86: Sager NP6110 3630QM 16GB ram, Tyan Thunder 2 2x 300Mhz
Sun: SS2 , LX , SS5 , SS10 , SS20 ,Ultra 1, Ultra 10 , T2000
Mac: Platinum Plus, SE/30
Back to top
View user's profile Send_private_message Visit_website 
Pizzasgood


Joined: 04 May 2005
Posts: 6270
Location: Knoxville, TN, USA

PostPosted: Wed 05 Nov 2008, 00:36    Post_subject:  

I don't think you're getting it yet.
Quote:
the only reason unleashed is so huge is that it includes the kernel... that is a binary package and should not be included
That's the main reason that the unleashed_core package is big, yes.

I'm not talking about only that package. I'm talking about the ENTIRE tree. As in, you've downoaded and extracted the unleashed_core, and then you've downloaded and extracted every .pet package from the petget repo and placed them in the tree. Now you're ready to start changing things.

At that point, the kernel stuff uses around 135 MB in Puppy 4.1's tree. The packages/ directory amounts for 858 MB.


But fortunately, SVN shrinks the entire 996 MB (including the non-kernel and non-packages/ stuff) down to around 270 MB.

Also, it seems that the bandwidth used to check out the trunk is also ~270 MB. Which means that you probably wouldn't save any bandwidth with the long convoluted mess I've been planning, where you'd grab the packages from the package server and overlay the SVN over them. However, doing that could get you better download speeds, especially right now while this is running from an old computer stashed under my bed...

Unfortunately, it seems that when you do the checkout and set up a working copy of that same data, the working copy expands to about 1.7 GB. I found that surprising, but I don't think it's a deal breaker.





Now that I have everything finished, when I get some more free time I can start seeing how it grows.


You should now be able to access the repo (through svn only) at svn://pizzasgood.no-ip.org/puppy, or svn://128.61.91.73/puppy, whichever floats your boat. I haven't gotten an opportunity to test this from off campus so I'm not entirely sure it will work, but I think it does. A word of warning: if nobody has accessed it in a while, it will probably hang for a bit when you first try to connect, until the lazy machine wakes up and restarts the harddrive. When I've finished experimenting with growth rates I'll look into setting up a web frontend.

If you're interested in navigating around in it, without actually checking anything out, you may be interested to hear that SVN has an "ls" option.
Code:
svn ls svn://pizzasgood.no-ip.org/puppy/

That way you can see what there is to see see see.


Read access is currently anonymous.

For write access, you need to log in.
Username: testperson
Pass: irnotreelyo


If you don't specifically give it parameters telling it who you are, it will probably ask you for the root password. Just hit enter, and it will give you a chance to input the username. Once you put int the username and password, your local svn client will cache that in /root/.subversion so that you don't have to enter it again. You can disable that in a configuration file somewhere.

I haven't set up the scripts to automate the first checkout yet, and as I said above, it turns out it's only a ~270 MB download to checkout the entire trunk. So you can either do that, or you can check out specific directories, files, etc. (Use the --depth=immediates option if you only want a specific level of the filesystem, without grabbing everything in its subdirectories).

Note - when I've said things like "check out the whole thing" I actually only meant the whole trunk. Do NOT check out the entire repository. That would involve also checking out every tagged version and every active branch. In this case, there are no branches yet and only one tagged version, so you'd "only" double your download size. In the future, and in other people's SVN repositories, there could be ten different tagged versions!


Assuming you want to check out the trunk to /mnt/sda4/puppy_svn_trunk, you would do this:
Code:
svn co svn://pizzasgood.no-ip.org/puppy/trunk /mnt/sda4/puppy_svn_trunk

If instead, you only wanted 0rootfs_skeleton-410, you would do something like this:
Code:
svn co svn://pizzasgood.no-ip.org/puppy/trunk/packages/0rootfs_skeleton-410 /mnt/sda4/0rootfs_skeleton-410


Then you can go in there and mess around. Don't mess with the .svn directories, you'll confuse SVN.

Here are links to more info on using SVN:
http://www.puppylinux.org/wiki/how-tos/general/subversionguide
http://svnbook.red-bean.com/



Here is the current layout of the repo:
Code:
bash-3.00# tree -d -L 4
.
`-- puppy
    |-- branches
    |-- tags
    |   `-- demo-1.00
    |       |-- packages
    |       `-- puppy-unleashed
    `-- trunk
        |-- packages
        |   |-- 0pkgs_db-4.00
        |   |-- 0pkgs_db-4.10
        |   |-- 0rootfs_skeleton-4.00
        |   |-- 0rootfs_skeleton-410
        |   |-- 915resolution-0.5.3-patched409
<SNIP>
        |   |-- zip-232
        |   |-- zlib-1.2.3
        |   `-- zmixer-0.2.1
        `-- puppy-unleashed
            |-- boot
            |-- isolinux-builds
            |-- kernels
            `-- packages -> ../packages





If you cannot connect to the repository, please tell me exactly what you did, how it behaved, and any error messages it gave (copy-paste directly from rxvt if possible). If the "pretty" address doesn't work, try the ip address. Also, see if you can attempt to connect to my ssh (ssh pizzasgood.no-ip.org). Obviously you won't have much chance of actually logging in through ssh, but it should at least say something like "permission denied". But do be aware that after you try five times, my computer will ignore your attempts at connecting with ssh for fifteen minutes or so. So don't let that confuse you. (No, it doesn't do that with SVN, only SSH).

And like I mentioned above, also be aware that it may take 10-20 seconds for my computer to get off it's lazy rear. I just wrote and started a simple bandwidth logging daemon, so maybe that will avoid this. Anyways, don't assume it isn't working until you actually get a timeout error.

_________________
Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib

Back to top
View user's profile Send_private_message Visit_website 
HairyWill


Joined: 26 May 2006
Posts: 2949
Location: Southampton, UK

PostPosted: Wed 05 Nov 2008, 06:14    Post_subject:  

Looking good
I checked out one of the absvolume packages
added a new file
and committed my changes
all looks rosy

As I was playing with svn I also had a look at retrovol. I like the look of the sliders and the desired feature list is impressive.

_________________
Will
contribute: community website, screenshots, puplets, wiki, rss
Back to top
View user's profile Send_private_message 
raffy

Joined: 25 May 2005
Posts: 4759
Location: Manila

PostPosted: Wed 05 Nov 2008, 07:35    Post_subject: subversion client  

Subversion client 1.3.1 is a pet package for Puppy 2 up to Puppy 3, so it is easy to add, no reboot required.

This helped me with a quick intro and commands:
http://www.yolinux.com/TUTORIALS/Subversion.html

Made a checkout (without target work area) and 8 MB of the trunk/unleashed got into /root/puppy. Transfer is a bit slow, but it's early evening here and that's expected. Smile

_________________
Puppy user since Oct 2004. Want FreeOffice? Get the sfs (English only).
Back to top
View user's profile Send_private_message 
Lobster
Official Crustacean


Joined: 04 May 2005
Posts: 15117
Location: Paradox Realm

PostPosted: Wed 05 Nov 2008, 09:39    Post_subject: Re: subversion client  


raffy wrote:
Puppy 3, so it is easy to add, no reboot required.


Thanks Raffy - I installed using Puppy 4.1.1 package manager (the SVN is under version 3 pets) and was able to use a few command lines immediately. I then got 'the fear of geek' and need to know if there is an SVN front end? Shocked

Pizzasgood has talked about creating a web based front end? Would this partially use javascript and or PHP to enable upload and download too?

At one time we did have some sort of revisioning system in Puppy main - what was it? Did it have a front end? It seems there is a serious and determined recognition by major developers that revisioning is essential. Good news Smile

There have been several previous attempts. I looked at a few myself. No real multi-developer support and so it never caught on. This time I am very hopeful.

It might be of interest a revisioning system I was involved in developing for the CURL language.
Curl is a language most comparable to PHP or possibly XUL
- however XUL is not available for Opera - so PHP is the better option.

Everything was done from a web interface.
We had two trees displayed in a webpage
The local and the remote. Once designated as a developer, you could download and work on a file locally and decide when it was ready to upload. You could also leave messages or notes about what you were doing etc. We kind of developed and used the system simultaneously.

Anyway feel free to use the 'Tick' name and logo if useful.
http://www.murga-linux.com/puppy/viewtopic.php?p=221033#221033

_________________
Puppy WIKI
Back to top
View user's profile Send_private_message Visit_website 
Display_posts:   Sort by:   
Page 1 of 4 Posts_count   Goto page: 1, 2, 3, 4 Next
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
 Forum index » Advanced Topics » Cutting edge
Jump to:  

Rules_post_cannot
Rules_reply_cannot
Rules_edit_cannot
Rules_delete_cannot
Rules_vote_cannot
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1766s ][ Queries: 12 (0.0145s) ][ GZIP on ]