I retired and am teaching myself Unix, and C with anticipation of learning LUA after that in an effort to keep 'the little grey cells' active
Therefore, in using Unix I have discovered files that I know nothing about, nor does unix man. I found .subversion and related files on my computer and I sure do not remember installing them. I have googled and left questions on Apple community. But I thought that I would try asking here, and hope that this is not too general a question(s)?
Does this thing come imbedded in downloads, say LUA or something from GCC?
Can I just go ahead and delete all things subversion?
Thank you
Subversion and many many other open source apps come preinstalled on your mac - it was there when you got it.
I'd recommend not deleting it - It's not hurting anything and trying to 'clean up' could lead to some unintended consequences.
Some other places to check out on the quest to keep the gray cells going:
https://apple.stackexchange.com/ -- all things mac and apple
https://serverfault.com/ -- questions relating to administrating and
running your machine.
Related
I need an old copy of the software Postnuke. I’m aware it’s outdated and discontinued but need to use it locally to use & convert a site which used to use this software.
I managed to find it using SourceForge (the 0.76 version) but it keeps hanging on the installation and I’m getting errors that don’t seem fixable to me on the step of inserting data (around 80%).
If any of the devs are around I’d really appreciate any assistance they could give me on how to get the “Set Login” stage working of the installer, specifically the start_postnuke() function because it’s missing the language and other variables from the PNconfig variable that are preventing it from installing.
I’m aware this is tagged as a Zikula question but it’s the only way I can find to try and contact who I assume are the developers of Postnuke.
You are right. Postnuke is dead. It died so long ago that nobody has any expertise. I doubt very much that installing the software is possible or truly necessary. You must have a database with info you are trying to access. Simply access it with whatever tools you are most comfortable with and pull and modify the data as needed. (fyi - I'm a former postnuke dev and current zikula dev. I've used PN since 0.62, so I know what I'm talking about).
If you really want to give it a go on getting a working installation I would recommend using the same server stack components that were "modern" at the time 0.76 was released. Apache, php, mysql. It will probably work then.
Since that time a lot of php functions have been made obsolete, and even syntax changed such as array shorthand notation.
But if you use a stack that's contemporary to that version, it should work.
I have been installing alot of Linux software lately. Installing almost always requires running a "configure" script. It has finally dawned on me that pretty much everyone is making their configure scripts by taking one extensive, generic script and tweaking it for their own purposes. If anyone knows what I am talking about, can you tell me the source for this generic configure script? Thanks.
That would be autoconf.
I would imagine that the Goat Book offers a comprehensive treatment of it.
Do not taunt autoconf.
I'm quite pretty new to the concept of CVS. However, I want to start using CVS and thus need to 'check-in' some scripts. I'm using a UNIX server and I know that CVS is installed, since doing a
cvs -v
Gives me the correct version number installed. Now the problem I have in is finding documentation to use CVS. Is there an online tutorial/FAQ someone can recommend. I've scoured Google for information and all I come across are posts for installing CVS ...
What I'm really looking for our sample commands taking a beginner from scratch like Logging in etc.
The meta-answer to your question is not to use CVS, unless you're participating in a project that's already using it. Even the CVS maintainers, as far as I understand, don't recommend it for new projects, but recommend svn instead. If you're being obliged to use it, then this answer isn't helpful; sorry.
If the decision is up to you, then you have alternatives:
svn is the system which is most similar to CVS (as noted in another answer).
Mercurial is a distributed version control system, but the distributed features aren't hugely important if, as your question vaguely suggests, you're working on your own.
Git has broadly the same model as Mercurial.
There are others (including at least bazaar and darcs), but those are the big three.
All of these are heavily used in both small projects and big ones.
I now tend to recommend Mercurial to people, and that's the one I predominantly use myself. There are holy wars possible about this, but I feel that's the one which has the best tradeoff between flexibility, good design, and usability (there's a longer version of this answer...!)
Update: there's a very good Mercurial introduction by Spolsky, which is well worth reading for rationale and pointers.
Use svn instead, lots of documentation for that.
Hmmm... a quick Google search for cvs tutorial returns this as the second hit:
http://www.linux.ie/articles/tutorials/cvs.php
I've quickly glanced over it, and Chapter 3 (Basic CVS Usage) starts with "Logging In" and seems to come pretty close to what you need. If you have any concrete questions, feel free to ask.
Here's the situation: at my small office, because we like to keep mobile and occasionally work from home, instead of having a central file server, we have all the office documents in an SVN repository, and each person keeps a checkout on their own laptops. A checkout weighs in at about 3GB, and the repo with revisions in it: about 6GB. This is all working great.
The problem is that soon we won't have a small office any more - all our 5 workers will be working remotely. I had considered purchasing a dedicated server and running our SVN repository from that, except two of our workers will be really remote and will be using wireless "broadband" with a 3GB/month limit, and I'm afraid that a few large updates will really rip through their monthly allowance, not to mention taking all day to complete.
Reading a few questions on Stack Overflow, it seems there's quite a community of distributed VCS aficionados who think git or mercurial is definitely the best for many situations. Given that all the employees would still be able to meet face-to-face at least once a fortnight (and hence be on a fast LAN), I'm wondering if a DVCS would work for us?
I don't know exactly what's in your repo, but unless you're changing all the files regularly, a DVCS should provide you a very desirable workflow.
You could do an svn -> git conversion, stick the repo on a DVD and mail it out to all the satellite offices, and then let them fetch from the office as things change at a fairly low incremental cost (should be smaller than the delta in general).
Checkout the Fossil DVCS, it may fit your bill. Fossil may be used like SVN or a DVCS. If you are concerned about it handling your current repository try it out. It also has a built in project wiki and bug tracking system that distribute with the repository as well. You could try it out and see if it would work for your small team.
The pain for you would be losing your revision history, at this time I don't beleive you can import a svn repository into Fossil.
Join the mailing list and you will get answers for any of your questions. The creator of SQLite is also the creator of this project as well. Hope this helps.
I can't see why not. With something like git, the repository is local to the machine, and so your remote employees can actually have a tracked changelog that can then be merged or rebased with the main repository--whatever you decide that to be--when they get the chance.
Also, git has really good compression compared to SVN, so the 3GB/mo quota may be more than enough for your remote employees.
Randal Schwartz actually gave a really good presentation on git at Google's Tech Talks: http://www.youtube.com/watch?v=8dhZ9BXQgc4
(It seems no one is answering this.) DVCS of course seems like it would work, but I have no experience with it. A centralized system like svn might also work if you are not expecting large changes daily. (to go up and back from the server) The initial get in that case would be the only real expensive issue.
Can you monitor your use now and see how much traffic goes back and forth?
The real problem here is the 3GB/mo bandwidth limitation. It's probably just better to come up with a better solution for connectivity...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
fossil http://www.fossil-scm.org
I found this recently and have started using it for my home projects. I want to hear what other people think of this VCS.
What is missing in my mind, is IDE support. Hopefully it will come, but I use the command line just fine.
My favorite things about fossil: single executable with built in web server wiki and bug tracking. The repository is just one SQLite (http://www.sqlite.org) database file, easy to do backups on. I also like that I can run fossil from and keep the repository on my thumb drive. This means my software development has become completely portable.
Tell me what you think....
Mr. Millikin, if you will take a few moments to review some of the documentation on fossil, I think your objections are addressed there. Storing a repository in an sQLite database is arguably safer than any other approach. See link text for some of the advantages of using a transactional database to store a repository. As for bloat: The entire thing is in a single self-contained executable which seems to disprove that concern.
Full disclosure: I am the author of fossil.
Note that I wrote fossil because no other DVCS met my needs. On the other hand, my needs are not your needs and so only you can judge whether or not fossil is right for you. But I do encourage you to at least have a look at the documentation and try to understand the problem that fossil is trying to solve before you dismiss it.
After having used Fossil for more than a year now on non-trivial development projects, I feel confident enough to weigh in on this topic.
Below is my experience so far. I'm comparing against git and svn at times, simply because I know those SCM's very well and comparing makes it easier for me to get the idea across.
I'm totally in love with this SCM, so it's mostly points on the plus side.
What I like about Fossil:
We have a bunch of machines (win/mac/a number of Linux distros), and the single-executable installation is just as beautiful as it sounds. No dependencies; it just works. Git is a messy pile of files and the dependency hell in Subversion makes it very nasty on some Linux distributions, especially if you must build it yourself.
The default Fossil workflow suits our projects perfectly, and more git'ish workflows are possible when needed.
We've found it extremely robust, even on large projects. I wouldn't expect anything else from the guys who wrote SQLite. No crashes, no corruption, no funny business.
I'm actually very, very happy with performance. Not as fast as git on huge trees, but not much slower either. I make up any lost time by not having to consult the documentation every other command, as is the case with git.
The fact that there's a tried'n'true transactional database behind every operation makes me sleep better at night. Yes, we've been through more than one horrible incident of stale and corrupt Subversion repositories (thankfully, a helpful community helped us fix them.) I can't imagine that happening in Fossil. Even Subversion 1.7.x use SQLite now for metadata storage. (Try turning off power in the midst of a git commit - it'll leave a corrupt repos!)
The integrated issue tracker and wiki are optional, obviously, but very handy as it's always there - no installation required. I wish the issue tracker had some more features though, but hey - it's an SCM.
The built-in server and web gui is simply brilliant and quite configurable through css.
We sometimes need to import to and from git and subversion repositories. This is a no-brainer in Fossil.
Single file repository. No '.svn' directories all over the place.
What I miss in / dislike about Fossil:
Someone please write TortoiseFossil for our non-technical Windows users :)
The community isn't that large yet, so it's probably hard for a lot of people to introduce it in their company. Hopefully this will change, gaining all the benefits of a large community (documentation, more testing of new releases, etc.)
I wish the local web ui had a search feature (including searching for file content).
Fewer merge options than in git (though the Fossil workflow makes merging less likely to occur in the first place.)
I hope everyone gives Fossil a run - the world is a better place with stuff that just works and which you don't need to be a rocket scientist to use.
Fossil is small, simple, yet powerful and robust, reminds me some principles of C Culture. Likable by those who develop independently and still collaborate.
Any great project should start with principles and continue them at its core as it gathers more layers (GUI, extra features).
I am impressed with Fossil and starting to use... take a look at fossil
cheers
I'm landing on this page after an year of the last post, recursive add that has been mentioned here is now taken care of.
Fossil mesmerizes me with simplicity especially after I struggled to get a bug-tracking system to work with mercurial. I need to see how to manage multiple projects, publish the repositories for multi-user access and how to do merging, manage patches etc. I get the feeling that it wont be disappointing going forward.
I'm not interested in using it for source-code version control, but I am interested in a distributed version-controlled personal wiki that I can sync between all the machines I use.
damian,
1/ yes, fossil doesn't support recursive add. However there are some fairly simply workarounds such as
for /r %i in (*.*) do fossil add "%i"
on Windows, and
find . -type f -print0 | xargs -0 fossil add --
on Unix.
2/ I saw the message about malformed manifest when you are adding a file with non-ASCII characters in the filename. The problem was corrected in the last build.
Regards,
Petr
I think fossil is really cool. The most important feature for me was easy installation, and developer friendly defaults. I currently use it to keep track of the local changes of my files. (Our project is hosted in sourceforge and kept track in CVS.) This way I can "commit" locally even if it would otherwise break the project, so smaller changes can be kept track as well.
Fossil is good. It is simple and easy to use. If fossil can provide GUI interface to check in and check out, then it would be better (prefer java gui to archive cross-platform GUI).
The main advantages of Fossil are "open source" and "use SQLite database", so somebody can compile fossil source code to make fossil work on google android platform (mobile and tablet devices).
I am trying your vcs right now.
I like the idea of having all integrated. After all, is all i want when i look for a system like this. I am an active user of Mercurial. And i couldn't find an integration with a issue tracker (I try unsuccessfully to set p Trac with mercurial in the past).
After some test i realize that:
1) "add" command is not recursively, or i can not found in the doc a way to do it
2) i write a bat (i work with windows) to add 750 files and i run it (it took a while). When a run commit it jumps with "manifest malformed"
i think you could address this issues and others making a survey like the Mercurial's one in https://www.mercurial-scm.org/wiki/UserSurvey.
you could write me at dnoseda at gmail
i am interested in you work. keep improve it.
regards
ps.: as an mayor improvement you could add something like gitstat
Perhaps an uneducated knee-jerk reaction, but the idea of storing a repository in a binary blob like an SQLite database terrifies me. I'm also dubious of the benefits of including wikis and bug trackers directly in the VCS -- either they're under-featured compared to full software like Trac, or the VCS is massively bloated compared to Subversion or Bazaar.