According to SF.net's news page, they are finally considering implementing
Subversion repositories. Here is the item:
> *Subversion Service: * The research, analysis, and support gear-up
> needed to implement a Subversion service at SourceForge.net is now in
> progress. As with all SourceForge.net services, extensive analysis and
> testing must be performed to verify suitable levels of stability and
> scalability before a service can be rolled-out. We are expecting the
> initial phases of this effort to last several weeks, to be followed by
> the implementation of a testing environment which will be used for a
> live beta test by specific selected projects. Pending successful
> scalability testing, service details will be finalized and service
> will be offered to all projects. (Last updated: 2005-03-02 Pacific)
Anyone who is familiar with CVS, but has had an opportunity to use
would never go back. Examples: (a)Try in CVS and SVN, renaming a directory
with 100 files in it. No contest. (b) An SVN branch is not a tagging,
but an actual branch of a
directory tree, with the branch diff'd from the trunk. (c) Commits are
meaning that a commit is not applied if it fails during transfer, but
only if it is
handled correctly. Very sweet.
It would be nice if Inkscape were one of the "specific selected projects".
Apologies that this isn't really related to Inkscape development, but...
I'm having real trouble with checking in the WordPress stuff I did. I
was up til nearly 2AM last night trying to get it to work (I got errors
when trying to commit), at which point I when to bed grumpily. Anyway,
today I finally got it to commit without any errors, but when I look at
the repository via the web interface
(http://cvs.sourceforge.net/viewcvs.py/inkscape/inkscape_web/) it seems
to have not worked right. The four WordPress-related directories have
checked in (wp-*), but NONE of the files seem to have. Furthermore, in
the wp-includes, wp-admin and wp-images directories, it seems the "cvs"
data directories have also checked in (which they shouldn't have),
again, without the files. I'm confused as hell, because the output in
the terminal when I committed seemed to be fine. For instance:
RCS file: /cvsroot/inkscape/inkscape_web/wp-includes/vars.php,v
Checking in wp-includes/vars.php;
/cvsroot/inkscape/inkscape_web/wp-includes/vars.php,v <-- vars.php
initial revision: 1.1
That, and other similar output suggests to me that it worked. But maybe
I'm missing something?
If anyone can help me out I'd be very grateful. I'm sure this is just my
newbie-ness but I can't see where I've gone wrong.
Also, on the topic of Subversion, I'd definitely support switching to
that -- this is the first time for me using CVS, but I have used
Subversion in the past with zero problems, and CVS is feels like an
Jonathan Leighton aka. Turnip
http://turnipspatch.com/ | http://digital-proof.org/
John Taber wrote:
>Hmm, one of the killer features that IE doesn't have and they are holding it
>back ? He does give a explanation of why re decisions on the feature
>conflicts - maybe our SVG community can help them out here. Or maybe should
>make available binaries of their SVG enabled CVS version?
Well, a person can already find an SVG-enabled version of Firefox, if
one looks hard enough. But how do you get this voodoo magic to the
masses, and the PHBs? It really needs to be in every browser.
What SVG needs for it to start gaining momentum is a user base.
Imagine if 6% of browsers in use already (FF's share) could display SVG
without any extensions or plugins. People would actually start putting
onto their sites. Maybe not completely; but a server could check
for "Accept: image/svg+xml", and for those lucky people show a detailed
SVG rather than a crappy bitmap. More content, more browsers; more
> All works for me. Please update to the latest CVS and if the problem
> persists file a detailed bug report (platform, libs, etc)
Woo-hoo, works here with latest CVS version! I can use Ctrl+letter and
Shift-Ctril+letter on obects, thanks!
Long time, no write ;-)
Still, I can't get the shortcuts to work with Russian layout, but now I
noticed the following: they do work for main menu and in other places (like
in text editor), but they do not work on the canvas. I am using last week's
cvs built from source.
So, say if I select an object, I can press Alt + E, C - this will follow to
the Edit menu and copy an object. I can trigger and browse any menu like this
Russian layout. In text editor, I can copy/cut/paste text (Ctrl + ...),
apply/close (), etc. But on canvas, none of the modifier keys work (and,
thus, shortcuts do not work either).
I remember that this problem exists since last spring, and I had 3 different
systems (and, thus, libraries configurations) since then.
I rebuilt this against autopackage 1.0 which provides misc bugfixes and
improvements. After this point you generally won't have to rebuild
packages to get improvements but 1.0 is the first API stable release so
it's necessary. The new package can be found here:
Could the one on SourceForge please be replaced? Also I noticed the
current package is corrupt on switch at least, so it'll give the mirrors a
chance to get non-truncated packages.
Hello everyone, I thought I would pull a Bulia and drop some features.
When doing web design and pre-layout, I found it annoying that I
could'nt get the hex value of colors, so I added a "Copy as Hex" button
when using the eye dropper to get a color value. This way, one can
quickly paste that into whatever web page they are working on...In the
meantime I did a few other tasks. There are a few things still necessary
to be done, but I wanted to report as I can't spend anymore time on it
right now...I need to make some money...
Made controls for Eye Dropper available on the auxiliary toolbar.
* Added entry boxes for hex values of last selected color and opacity.
* Added "Copy as RGBA" button that copies last selected color as RGBA
value to the clipboard
* Added "Copy as HEX" button that copies the last selected color as a
HEX value (useful for web work where hex values are needed)
* Added toggle switch option to select current color as visible on
screen without alpha. When not toggled, then the current color and
opacity as represented with alpha becomes the stored desktop value.
* Removed the aforementioend option from the application preferences
menu, as it is now available via the dropper auxiliary toolbar.
What still needs to be done:
1.) I made an icon for the toggled value for Picking a color, I think
called "pick_color" in icons.svg. I couldn't come up with a good one, so
maybe someone could come up with a better icon to replace the crappy one
I did for the toggle button.
2.) I need to fix HEX values that are copied when the option to pick
color with alpha is selected. I know how to fix, but just don't have
time right now to do...it is a simple thing...but I'm slow right now.
3.) I'm sure there are some things I missed since I did this quickly.
Please email/fix/post bugs about...