php-general Digest 2 Jan 2009 08:48:05 -0000 Issue 5878
Topics (messages 285351 through 285367):
Re: IE Problem Detecting Post Variables
285351 by: Ashley Sheridan
285356 by: Bastien Koert
285358 by: Ashley Sheridan
285367 by: L. Herbert
Thank you everyone, What a wonderful world
285352 by: Behzad
Re: PHP telnet server
285353 by: Robert Cummings
285354 by: Robert Cummings
285355 by: Robert Cummings
285357 by: Luke Slater
285359 by: Per Jessen
285362 by: Robert Cummings
285363 by: Robert Cummings
285364 by: Luke Slater
285365 by: Robert Cummings
285366 by: Luke Slater
Re: Encryption/decryption of PHP data
285360 by: Per Jessen
Re: Question about version control.. sorta..
285361 by: Nathan Nobbe
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On Thu, 2009-01-01 at 11:25 -0500, Phpster wrote:
> What about using the onclick to set a js variable to be sent to the
> server? That should be more cross server compliant.
>
> Bastien
>
> Sent from my iPod
>
> On Dec 31, 2008, at 8:37 PM, "L. Herbert" <lherb...@iluvmydesign.com>
> wrote:
>
> > Bastien,
> >
> > Thanks for your response. The curious thing is that the value is
> > passed when using FF, but not passed when using IE.
> >
> > Here is the relevant form html:
> >
> > <div id="switch-theme">
> > <form action="" method="post">
> > <label>Flip It!</label>
> > <input name="style" type="image" src="images/
> > switch-button-grey.gif" title="Default Theme" id="style1"
> > value="default" />
> > <input name="style" type="image" src="himages/
> > switch-button-default.gif" title="Alternate Theme" id="style2"
> > value="alternate" />
> > </form>
> > </div>
> >
> > The action attribute is left blank so the form posts to the current
> > page. The theme switcher script is at the top of each page and
> > intercepts the posted variables.
> >
> > Any thoughts?
> >
> >
> > On Dec 31, 2008, at 11:02 AM, Phpster wrote:
> >
> >> Try checking to see if the value was passed with var_dump($_REQUEST)
> >>
> >> Also try (!empty($_REQUEST['style']))
> >>
> >>
> >> Bastien
> >>
> >> Sent from my iPod
> >>
> >> On Dec 31, 2008, at 10:24 AM, "L. Herbert"
> >> <lherb...@iluvmydesign.com> wrote:
> >>
> >>> Hello all,
> >>>
> >>> Anyone have insight to share on the following issue:
> >>>
> >>> I have a simple theme switcher script that functions as expected
> >>> in FF, Safari, etc. but does not work in IE 6 or 7. It appears
> >>> that the posted form variables are not detected in IE. I am
> >>> using the following check within the script:
> >>>
> >>> if(isset($_REQUEST['style'])) {
> >>>
> >>> $style = $_REQUEST['style'];
> >>> }
> >>>
> >>> Thanks in advance for your assistance.
> >>>
> >>> --
> >>> PHP General Mailing List (http://www.php.net/)
> >>> To unsubscribe, visit: http://www.php.net/unsub.php
> >>>
> >>
> >> --
> >> PHP General Mailing List (http://www.php.net/)
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >
>
Which would make it as non-accessibility-friendly as possible...
Ash
www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On Thu, Jan 1, 2009 at 11:59 AM, Ashley Sheridan
<a...@ashleysheridan.co.uk>wrote:
> On Thu, 2009-01-01 at 11:25 -0500, Phpster wrote:
> > What about using the onclick to set a js variable to be sent to the
> > server? That should be more cross server compliant.
> >
> > Bastien
> >
> > Sent from my iPod
> >
> > On Dec 31, 2008, at 8:37 PM, "L. Herbert" <lherb...@iluvmydesign.com>
> > wrote:
> >
> > > Bastien,
> > >
> > > Thanks for your response. The curious thing is that the value is
> > > passed when using FF, but not passed when using IE.
> > >
> > > Here is the relevant form html:
> > >
> > > <div id="switch-theme">
> > > <form action="" method="post">
> > > <label>Flip It!</label>
> > > <input name="style" type="image" src="images/
> > > switch-button-grey.gif" title="Default Theme" id="style1"
> > > value="default" />
> > > <input name="style" type="image" src="himages/
> > > switch-button-default.gif" title="Alternate Theme" id="style2"
> > > value="alternate" />
> > > </form>
> > > </div>
> > >
> > > The action attribute is left blank so the form posts to the current
> > > page. The theme switcher script is at the top of each page and
> > > intercepts the posted variables.
> > >
> > > Any thoughts?
> > >
> > >
> > > On Dec 31, 2008, at 11:02 AM, Phpster wrote:
> > >
> > >> Try checking to see if the value was passed with var_dump($_REQUEST)
> > >>
> > >> Also try (!empty($_REQUEST['style']))
> > >>
> > >>
> > >> Bastien
> > >>
> > >> Sent from my iPod
> > >>
> > >> On Dec 31, 2008, at 10:24 AM, "L. Herbert"
> > >> <lherb...@iluvmydesign.com> wrote:
> > >>
> > >>> Hello all,
> > >>>
> > >>> Anyone have insight to share on the following issue:
> > >>>
> > >>> I have a simple theme switcher script that functions as expected
> > >>> in FF, Safari, etc. but does not work in IE 6 or 7. It appears
> > >>> that the posted form variables are not detected in IE. I am
> > >>> using the following check within the script:
> > >>>
> > >>> if(isset($_REQUEST['style'])) {
> > >>>
> > >>> $style = $_REQUEST['style'];
> > >>> }
> > >>>
> > >>> Thanks in advance for your assistance.
> > >>>
> > >>> --
> > >>> PHP General Mailing List (http://www.php.net/)
> > >>> To unsubscribe, visit: http://www.php.net/unsub.php
> > >>>
> > >>
> > >> --
> > >> PHP General Mailing List (http://www.php.net/)
> > >> To unsubscribe, visit: http://www.php.net/unsub.php
> > >>
> > >
> >
> Which would make it as non-accessibility-friendly as possible...
>
>
> Ash
> www.ashleysheridan.co.uk
>
>
There are always trade-offs
--
Bastien
Cat, the other other white meat
--- End Message ---
--- Begin Message ---
On Thu, 2009-01-01 at 12:57 -0500, Bastien Koert wrote:
> On Thu, Jan 1, 2009 at 11:59 AM, Ashley Sheridan
> <a...@ashleysheridan.co.uk>wrote:
>
> > On Thu, 2009-01-01 at 11:25 -0500, Phpster wrote:
> > > What about using the onclick to set a js variable to be sent to the
> > > server? That should be more cross server compliant.
> > >
> > > Bastien
> > >
> > > Sent from my iPod
> > >
> > > On Dec 31, 2008, at 8:37 PM, "L. Herbert" <lherb...@iluvmydesign.com>
> > > wrote:
> > >
> > > > Bastien,
> > > >
> > > > Thanks for your response. The curious thing is that the value is
> > > > passed when using FF, but not passed when using IE.
> > > >
> > > > Here is the relevant form html:
> > > >
> > > > <div id="switch-theme">
> > > > <form action="" method="post">
> > > > <label>Flip It!</label>
> > > > <input name="style" type="image" src="images/
> > > > switch-button-grey.gif" title="Default Theme" id="style1"
> > > > value="default" />
> > > > <input name="style" type="image" src="himages/
> > > > switch-button-default.gif" title="Alternate Theme" id="style2"
> > > > value="alternate" />
> > > > </form>
> > > > </div>
> > > >
> > > > The action attribute is left blank so the form posts to the current
> > > > page. The theme switcher script is at the top of each page and
> > > > intercepts the posted variables.
> > > >
> > > > Any thoughts?
> > > >
> > > >
> > > > On Dec 31, 2008, at 11:02 AM, Phpster wrote:
> > > >
> > > >> Try checking to see if the value was passed with var_dump($_REQUEST)
> > > >>
> > > >> Also try (!empty($_REQUEST['style']))
> > > >>
> > > >>
> > > >> Bastien
> > > >>
> > > >> Sent from my iPod
> > > >>
> > > >> On Dec 31, 2008, at 10:24 AM, "L. Herbert"
> > > >> <lherb...@iluvmydesign.com> wrote:
> > > >>
> > > >>> Hello all,
> > > >>>
> > > >>> Anyone have insight to share on the following issue:
> > > >>>
> > > >>> I have a simple theme switcher script that functions as expected
> > > >>> in FF, Safari, etc. but does not work in IE 6 or 7. It appears
> > > >>> that the posted form variables are not detected in IE. I am
> > > >>> using the following check within the script:
> > > >>>
> > > >>> if(isset($_REQUEST['style'])) {
> > > >>>
> > > >>> $style = $_REQUEST['style'];
> > > >>> }
> > > >>>
> > > >>> Thanks in advance for your assistance.
> > > >>>
> > > >>> --
> > > >>> PHP General Mailing List (http://www.php.net/)
> > > >>> To unsubscribe, visit: http://www.php.net/unsub.php
> > > >>>
> > > >>
> > > >> --
> > > >> PHP General Mailing List (http://www.php.net/)
> > > >> To unsubscribe, visit: http://www.php.net/unsub.php
> > > >>
> > > >
> > >
> > Which would make it as non-accessibility-friendly as possible...
> >
> >
> > Ash
> > www.ashleysheridan.co.uk
> >
> >
> There are always trade-offs
>
for me, losing accessibility at the expense of some work to fix the
problem is not a trade-off at all. I'd always go for accessibility
first.
Ash
www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
I find the html/php option simpler and more "accessible". I've got it
working now. I only needed to use unique input names and test for the
posted variable according to w3c standards.
Here is the relevant w3c definition:
"When a pointing device is used to click on the image, the form is
submitted and the click coordinates passed to the server. The x value
is measured in pixels from the left of the image, and the y value in
pixels from the top of the image. The submitted data includes name.x=x-
value and name.y=y-value where "name" is the value of the name
attribute, and x-value and y-value are the x and y coordinate values,
respectively."
PHP modifies the posted variable name to name_x, name_y to comply with
PHP's variable naming convention requirements.
Thanks to those all responded for pointing me in the right direction.
On Jan 1, 2009, at 11:25 AM, Phpster wrote:
What about using the onclick to set a js variable to be sent to the
server? That should be more cross server compliant.
Bastien
Sent from my iPod
On Dec 31, 2008, at 8:37 PM, "L. Herbert"
<lherb...@iluvmydesign.com> wrote:
Bastien,
Thanks for your response. The curious thing is that the value is
passed when using FF, but not passed when using IE.
Here is the relevant form html:
<div id="switch-theme">
<form action="" method="post">
<label>Flip It!</label>
<input name="style" type="image" src="images/
switch-button-grey.gif" title="Default Theme" id="style1"
value="default" />
<input name="style" type="image" src="himages/
switch-button-default.gif" title="Alternate Theme" id="style2"
value="alternate" />
</form>
</div>
The action attribute is left blank so the form posts to the current
page. The theme switcher script is at the top of each page and
intercepts the posted variables.
Any thoughts?
On Dec 31, 2008, at 11:02 AM, Phpster wrote:
Try checking to see if the value was passed with var_dump($_REQUEST)
Also try (!empty($_REQUEST['style']))
Bastien
Sent from my iPod
On Dec 31, 2008, at 10:24 AM, "L. Herbert" <lherb...@iluvmydesign.com
> wrote:
Hello all,
Anyone have insight to share on the following issue:
I have a simple theme switcher script that functions as expected
in FF, Safari, etc. but does not work in IE 6 or 7. It appears
that the posted form variables are not detected in IE. I am
using the following check within the script:
if(isset($_REQUEST['style'])) {
$style = $_REQUEST['style'];
}
Thanks in advance for your assistance.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Hi List,
I would like to appreciate from you all. I hope that you enjoy your
holidays.
Children (yes! children) are dying in Gaza, and we're safe! We're happy.
Happy Christmas!!
Thank you for supporting Israel, and for being so quite. The God is with
you!
How Palestinians defend(!) themselves with stones, and how Zionist are
performing
a new holocaust using the American weapons in a prison, named Gaza strip.
But you now what... this is really good. At least this could bring
democracy, and freedom to
middle east. PEACE! HUMAN RIGHTS! YEAH! a lot of bullshit !!.
We're all responsible for this event. What a shame for mankind in 21th
century.
Forget this. This is SPAM and/or PROPAGANDA!
CHEERS!
-behzad
--- End Message ---
--- Begin Message ---
On Thu, 2009-01-01 at 11:51 +0100, Per Jessen wrote:
> Robert Cummings wrote:
>
> >>
> >> It's not easy in any language, but if your key concern is the
> >> performance of PHP (as a language), hardware is what you need. You
> >> can design your software to run on a single box with lots of CPU
> >> cores, or
> >> you can go for a distributed (and more easily scalable) approach. If
> >> you don't need/want straight scalability, go for the 32 cores all
> >> ticking at 3GHz. Once that is saturated, buy another one.
> >
> > If you go multi core then you need to go with a threaded approach...
> > which makes the development a bit complex for newbies to MUD
> > development.
>
> 'c...@l-i-e.com' doesn't seem like a newbie to me, but you're right, it
> would be a complex job for a newbie.
'c...@l-i-e.com' isn't the original poster, I was speaking generally...
with a possibly nod towards the OP who may be a newbie.
> Nevertheless, given todays
> machines where even laptops have multiple cores, I would certainly
> design any new performance-critical application for multi-threading.
> (Multi-threading in PHP is a challenge in itself, and I wouldn't choose
> PHP for such a job, but that's a different story).
>
> > I don't think I'd go distributed since people whine about
> > lag that takes a 1/4 second... distributed would inherently require
> > more time while messages are passed to and fro.
>
> That is perhaps a valid consideration, but isn't it easily dealt with by
> using gigabit ethernet or infiniband or something similar?
We're talking about a text-based MUD here... it's unlikely the user has
the will to spring for such resources for this endeavour.
> The distributed vs. one big monolith discussion is also a matter of
> space, cooling, electricity etc. The big monolith is easier to deal
> with, but also carries a different pricetag. The many machines can be
> gradually expanded at a lower cost, but need much more in terms of
> infrastructure.
Yes, I agree with all your points, just think perhaps you've shot past
the target a little ;)
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
On Thu, 2009-01-01 at 12:53 +0000, Luke Slater wrote:
> Well the current system runs of a 20MB internet connection in London,
> seeing as that's the UK that about 2MB.
>
> It runs fine, responses are snappy even dealing with loads of users.
>
> This, however, is written in C: does PHP have that much of an overhead so
> that bandwidth is actually that much of an issue?
No the issue was a distributed environment for the MUD that would
introduce internal network latency as the machines coordinate amongst
themselves.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
On Thu, 2009-01-01 at 13:27 +0000, Luke wrote:
> The current system also uses some kind of strange text based database, I was
> wondering if using MySQL for the database would slow it down too much?
Which MUD engine are you using? Chances are it's DIKU, or Circle, or
Merc or one of the many derivatives. I converted ours years ago from
that horrible text format to XML... not that everyone thinks XML is the
bee's knees, but it's certainly more flexible than DIKU flat file. MySQL
can work, but I don't suggest it as a straight up format. I suggest
something like XML (or any other flexible markup language) which is then
housed in a MySQL database. You may enjoy the pain of managing 60
different tables though for an object... or not :)
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
It's actually derived from tinymud.
XML is another option, however I've had people tell me not to use that
because it's horrifically slow, even though I've used it extensively,
through AJAX before and never had a speed issue; although perhaps when
dealing with more information it does become an issue?
On Thu, 1 Jan 2009, Robert Cummings wrote:
On Thu, 2009-01-01 at 13:27 +0000, Luke wrote:
The current system also uses some kind of strange text based database, I was
wondering if using MySQL for the database would slow it down too much?
Which MUD engine are you using? Chances are it's DIKU, or Circle, or
Merc or one of the many derivatives. I converted ours years ago from
that horrible text format to XML... not that everyone thinks XML is the
bee's knees, but it's certainly more flexible than DIKU flat file. MySQL
can work, but I don't suggest it as a straight up format. I suggest
something like XML (or any other flexible markup language) which is then
housed in a MySQL database. You may enjoy the pain of managing 60
different tables though for an object... or not :)
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Robert Cummings wrote:
> 'c...@l-i-e.com' isn't the original poster, I was speaking generally...
I thought he was the one to bring up his concern about PHP and
performance - I could be wrong.
>> That is perhaps a valid consideration, but isn't it easily dealt with
>> by using gigabit ethernet or infiniband or something similar?
>
> We're talking about a text-based MUD here... it's unlikely the user
> has the will to spring for such resources for this endeavour.
I guess my ignorance or age (or both) is showing, I have no idea what
a "text-based MUD" is. I thought we were talking some network gaming
engine a la WoW and such.
I still think my initial response was appropriate though - if PHP as a
language is a performance concern, it's best solved by throwing more
hardware at it. If that is not an option, don't use PHP.
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
On Thu, 2009-01-01 at 19:03 +0100, Per Jessen wrote:
> Robert Cummings wrote:
>
> > 'c...@l-i-e.com' isn't the original poster, I was speaking generally...
>
> I thought he was the one to bring up his concern about PHP and
> performance - I could be wrong.
>
> >> That is perhaps a valid consideration, but isn't it easily dealt with
> >> by using gigabit ethernet or infiniband or something similar?
> >
> > We're talking about a text-based MUD here... it's unlikely the user
> > has the will to spring for such resources for this endeavour.
>
> I guess my ignorance or age (or both) is showing, I have no idea what
> a "text-based MUD" is. I thought we were talking some network gaming
> engine a la WoW and such.
Text MUDs are the precursor to graphical MUDs. They have been around for
about 30-40 years now I think. They still exist with various fan-bases
all around the world. They are still a great project for cutting one's
teeth into programming since they cover so many different aspects of
programming. They are usually played over telnet.
http://www.wocmud.org :)
telnet wocmud.org 4000
They are however, not nearly as popular as they once were due to the
pervasiveness of graphical muds such as the aforementioned WoW and
before it Ultima Online, EverQuest, etc.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
On Thu, 2009-01-01 at 17:58 +0000, Luke Slater wrote:
> It's actually derived from tinymud.
>
> XML is another option, however I've had people tell me not to use that
> because it's horrifically slow, even though I've used it extensively,
> through AJAX before and never had a speed issue; although perhaps when
> dealing with more information it does become an issue?
XML can have speed issues, but generally speaking not that much to worry
about, especially since area files are usually loaded at boot time and
the data cached as a template for creating mobs/items on future load
requests. The flexibility though, to me, makes it a must have trade-off.
Also, my MUD's player files are XML also. There's so much convienve
being able to hand edit a player file when issues arise, or even cut and
past items from a backup player file into an existing player file. These
things used to be binary and everytime the player structure was changed
you'd need to do a player file import/export process to update the
format. Now there's no dependency like that.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
WELL, while we're advertising, tcz.net
telnet tcz.net 23
The MUD does indeed cover many aspects of programming, most of them even
have their own scripting language!
On Thu, 1 Jan 2009, Robert Cummings wrote:
On Thu, 2009-01-01 at 19:03 +0100, Per Jessen wrote:
Robert Cummings wrote:
'c...@l-i-e.com' isn't the original poster, I was speaking generally...
I thought he was the one to bring up his concern about PHP and
performance - I could be wrong.
That is perhaps a valid consideration, but isn't it easily dealt with
by using gigabit ethernet or infiniband or something similar?
We're talking about a text-based MUD here... it's unlikely the user
has the will to spring for such resources for this endeavour.
I guess my ignorance or age (or both) is showing, I have no idea what
a "text-based MUD" is. I thought we were talking some network gaming
engine a la WoW and such.
Text MUDs are the precursor to graphical MUDs. They have been around for
about 30-40 years now I think. They still exist with various fan-bases
all around the world. They are still a great project for cutting one's
teeth into programming since they cover so many different aspects of
programming. They are usually played over telnet.
http://www.wocmud.org :)
telnet wocmud.org 4000
They are however, not nearly as popular as they once were due to the
pervasiveness of graphical muds such as the aforementioned WoW and
before it Ultima Online, EverQuest, etc.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
On Thu, 2009-01-01 at 18:43 +0000, Luke Slater wrote:
> WELL, while we're advertising, tcz.net
>
> telnet tcz.net 23
>
> The MUD does indeed cover many aspects of programming, most of them even
> have their own scripting language!
Which is why PHP seems so lucrative... but one thing you need to keep in
mind by using PHP as an in-game item/mobile scripting engine... is that
you have to either trust all your builders or sandbox the PHP engine in
such instances so that malicious code can't do damage.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
Well, I'm only 16 and I'm using 'em.
They are pretty good but depreceated rather a lot as graphical MUDs came
around.
The people on them are generally of the, ah, computing persuasion though
so it's a good way to meet people with like interests :)
On Thu, 1 Jan 2009, Per Jessen wrote:
Robert Cummings wrote:
'c...@l-i-e.com' isn't the original poster, I was speaking generally...
I thought he was the one to bring up his concern about PHP and
performance - I could be wrong.
That is perhaps a valid consideration, but isn't it easily dealt with
by using gigabit ethernet or infiniband or something similar?
We're talking about a text-based MUD here... it's unlikely the user
has the will to spring for such resources for this endeavour.
I guess my ignorance or age (or both) is showing, I have no idea what
a "text-based MUD" is. I thought we were talking some network gaming
engine a la WoW and such.
I still think my initial response was appropriate though - if PHP as a
language is a performance concern, it's best solved by throwing more
hardware at it. If that is not an option, don't use PHP.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Edward Diener wrote:
>> why not just use https protocol. all data between client and server
>> will be encrypted.
>
> The data must be encrypted/decrypted going both ways between the
> client and the server. Does using https automatically do that ? If it
> does that would be great.
>
Yes, that is exactly what https does.
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
On Thu, Jan 1, 2009 at 7:33 AM, TG <tg-...@gryffyndevelopment.com> wrote:
> Thanks for the recommendations, everyone. I decided to give Subversion
> another try, since I had a server already set up from when I tried this a
> while ago. Reinstalled TortoiseSVN for Windows and got it all configured.
> But I couldn't figure out how to update existing files in the repository
> without checking them out.
you cant. you can basically just browse, but you can also do things like
branch and delete (well things always stay in svn but still). if you want
to change the contents of files or do merges, youll need to have a working
copy.
> I tried using the RepoBrowser and I could add
> new items by dragging them to the browser, but if I tried to drag something
> that already existed, I got an error.
never touched RepoBrowser.., i tend to stick to the cli :)
> Is there any way to reimport as a new version? In particular, I'd love to
> have it just import changed files.
everything in svn is based around 'changesets'. its pretty easy to pull
them up and apply them to working copies. for example say you wanted the
diff between version 1 and 4,
svn diff -r 1:4 svn://mysvnurl
I'd love to also be able to select a date and get a copy of the directory in
> question as it appeared on that date.
easy, use svn log and grep for the date in question. once youve found that
you can get a snapshot of the entire repository as it appeared on any commit
from that day.
I'm sure there's ways to do this with SVN, but it's eluding me. I'll keep
> looking, but I'm thinking that SVN is overkill for what I need, even though
> it's in the right ballpark.
svn is pretty simple, but you will have to spend some time on it for it to
make sense. it sounds like you want something very simple. maybe something
like quilt,
http://savannah.nongnu.org/projects/quilt/
is better? im sure its limited, but there is a newer system called StGit as
well that uses git as the backend.
The other option mentioned, FileHamster, has potential, but I'd rather
> control my own server and storage requirements. Plus I didn't see a way to
> either whitelist of blacklist file types.
if you mean, youd like to prevent certain files from making it into the
repository then w/ svn, a commit hook would be sufficient.
> I really just want to back up
> script files and not the PDFs and other large files. So either
> whitelisting by file type (or blacklisting if necessary) or even doing it
> by file size would be fine.
rather than a commit hook or in tandem w/ it, most people just choose not to
commit certain files to the repository out of practice. these can also be
hidden from view, essentially by placing filenames / patterns via the
svn:ignore property
My web host supports rsync, but I don't think I've seen any version control
> options for rsync.
does your webhost support svn clients? you can do svn co then svn up, svn
switch etc.
-nathan
--- End Message ---
