Could the owners of the list remove me from this, that is from all
lists hosted on tigris.org, please?
Last March I tried to do so, just as futile as later on in summer
again when I anticipated getting into PHP, Perl, Python, MySQL for
a major relaunch of websites here, leaving no time to scan 150-200
list mails per day. However, neither sending command mails to the
list server as described in the help received on subscription nor use
of the unsubscribe link in the head of list mails had any effect. On
the websites I could not get any further, probably as there was no
registration needed back when I subscribed. But to register now to
become unlisted is IMNSHO spammers' behaviour. Having more to
do then I had simply not collected any mail from this account
since, but now would like to use it again (not for list mail for sure).
I can filter new mail to be deleted or returned, but can delete old
mail only 10 by 10 through a web interface - with some 6 or 7000
mails in the box...
Thank you for your attention and also many thanks to Ben and Karl
and Branko and all the other helpful minds on these lists.
However, it has not worked out here: while the problems changed,
they became ever more subversive, and with updates or even re-
install of versions once working here no longer possible we have
closed this chapter.
Best regards,
Jan Hendrik
PS: For pure curiosity I tried to set up SVN 1.1.2 with Apache on
Monday, but Apache still won't start as soon as any one of the
SVN modules is activated. Used the ZIP package for the installer
had wrecked Apache in the past twice. So either the path problem
Tobias Ringstroem mentioned was too exotic to make it into
releases or our problem is something different. Looks like an
imcompatibility between SVN and one or more of PHP 4.3.9, Perl
5.8 (ActiveState), MySQL 4.0, and Python 2.3. Otherwise
Win2000 SP2 (maybe that is not supported anymore...) and
Apache 2.0.52.
Concerning Re: File not found: transaction `2eb`....... Tobias
Ringström wrote on 25 Oct 2004, 11:06, at least in part:
> Jan Hendrik wrote:
>
> >As a follow-up:
> >
> >Tried to get back to the last version of Subversion working with
> >Apache on a Windows machine - SVN 1.0.6 - and uninstalled SVN 1.1,
> >installed 1.1.1 (Apache won't start either), uninstalled once more,
> >and set up 1.0.6. Obviously uninstall leaves something behind in the
> >registry as now 1.0.6 stops Apache from starting just
> >
> >
> I think "obviously" is a little strong.
You were right, Tobias, uninstall of SVN 1.0.8/1.1 had left nothing
behind. A worm infection provided me with a new setup and there
SVN 1.0.6 would stop Apache starting as well the moment any one
of the SVN modules is included.
This is too complex for me nor do I have the time to get into it. The
only thing I can see is some sort of incompatibility with one or
more of PHP, Perl, MySQL, Kerio Personal Firewall. Originally I
had started with SVN 0.27 and updated more or less regularly.
Later on those other applications were added. Being more
important for me than SVN this time SVN (1.0.6) was added *after*
PHP etc. and did not work, even though before the worm infection
1.0.6 had worked till that upgrade attempt. On some other
research I read in a forum that newer versions of SVN/TSVN are
incompatible with SVN 1.0.6 server.
Meanwhile we had centralized version control: working copies were
put into shared folders and folks wrote down their commit notes.
Every other day or so I walk down to the machine with the
repository and commit/update all the working copies on the LAN
(mind: the repository is on the same machine and accessed
through Apache). Slow and annoying, but at least folks have no
longer to call me every hour. And I see first hand that all those
subversive issues are real, not caused by wrong handling of
SVN/TSVN. To mention just the last few:
- using TSVN on machine A file X was renamed to Y. As far as A
is concerned everything is fine. But neither the delete nor the add
part of the remane is listed for commit on A. Y never reaches the
repository...
- user A adds an anchor tag to a HTML paragraph and commits.
Fine. User B updates and gets a conflict in this paragraph: SVN
says B had added another anchor tag, too. Looking at B's base
indicates that he has indeed. However, B's "new" anchor is
already in A's paragraph and is on the production server and is in
all working copies. In fact it is there since the file was created a
few years ago...
No word on the 2.5 days nightmare to get the rename of several
thousand files from HTML to PHP committed. In wise foresight I
had not considered SVN & branching for the many steps of this
transformation, but used ZIP files instead. In the end it were these
and a dumpfile that saved my work before one commit finally
succeeded. Well, one doesn't look into a donated horse's mouth.
We are now abolishing SVN, returning to a daisy-chained
combination of simple file sync and use of WinMerge. Probably we
will have a look at CVS soon. Wouldn't wonder to find CVS being a
seasoned and reliable system most noticable for not being noticed
at all. Once I was commissioned to another unit in our squad with
a very bad reputation, only to find it having the finest crew I ever
joined.
Of course it's all my own mistake. Never should I have disregarded
the good old rule of never using software that has not yet hit version
2 as the very least. I am neither a skilled programmer nor do I have
the means of compilers etc. to find fun in hacking source code.
What we need here are tools that work, and as we do not program
coding but produce content this may well be another
misunderstanding on my part: web content and program code are
as similar as apples and oranges.
Good luck!
Jan Hendrik
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 5 18:45:33 2005