You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Arved Sandstrom <Ar...@chebucto.ns.ca> on 2000/05/18 04:36:59 UTC
New CVS Branch
OK, as we discussed, I created a new branch that is intended to serve as the
basis for any intermediate efforts leading to the shortly forthcoming 0.13.0
interim release.
Here's what I did:
(1) Updated my working copy;
(2) Created the new branch with
cvs tag -b release-0-13-0
I also then immediately created a new directory elsewhere, and did a
cvs checkout -r release-0-13-0 xml-fop
into that directory. My reason for doing so was to verify the preceding
operation, and to give myself one working copy (the original) which is on
the main trunk, intended for the FOP 1.0 efforts, and one separate working
copy which is on the branch, so that any commits I do in _that_ working copy
will only affect the maintenance release.
You don't have to do it this way: if you'd like to temporarily switch your
working copy over to the new branch then do
cvs update -r release-0-13-0
in your working copy.
I'd appreciate it if committers/developers check all of this out. Most of
CVS is new to me, too.
If you don't do anything different whatsoever, and continue business as
usual, your commits should affect the main trunk, that is, the code intended
for the FOP 1.0 release.
Please let me know if you think anything screwed up. Thank you.
Arved Sandstrom
P.S. At some point, roughly a week from now, but maybe later (who knows),
we'll tag the files as they are on the maintenance (release-0-13-0) branch,
and use the files in that state for producing an interim FOP JAR.
Re: New CVS Branch
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
The light at the end of the tunnel here is that it tells me exactly where
the permissions were messed up in my working copies, so I can fix them. I
thought I was OK, but obviously not.
This also tells me why the Ant method for building FOP was working fine on
Windows, but not on Linux. I went off on a wild-goose chase about
classpaths, but it was clearly a permissions problem.
Arved
At 12:59 PM 5/18/00 +0200, Fotis Jannidis wrote:
>Hi Arved,
>
>> I guess I've got the same problem as you do. I do actually have the /lib
>> dir, and it contains a /bin directory, and both are tagged to the new
branch
>> after I run the same command you did, but they are empty.
>
>I have added /lib and some files and dirs under /docs/examples which were
also
>missing. While I am at it I'll also add /images and /resources. I hope I
get everything
>right.
>
>Fotis
Re: New CVS Branch
Posted by Fotis Jannidis <Fo...@lrz.uni-muenchen.de>.
Hi Arved,
> I guess I've got the same problem as you do. I do actually have the /lib
> dir, and it contains a /bin directory, and both are tagged to the new branch
> after I run the same command you did, but they are empty.
I have added /lib and some files and dirs under /docs/examples which were also
missing. While I am at it I'll also add /images and /resources. I hope I get everything
right.
Fotis
Re: New CVS Branch
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
Hi, Fotis
I guess I've got the same problem as you do. I do actually have the /lib
dir, and it contains a /bin directory, and both are tagged to the new branch
after I run the same command you did, but they are empty.
The only thing I can figure is that in my Linux working copy, that for one
reason or another, the CVS entries in that particular entry do not detail
any entries, and hence no files in that directory actually got tagged,
although I do know that they physically exist. I don't know why this would
be so but it's one explanation. The other explanation is that I got bit with
a permissions thing. I try to be careful to do everything as a user, not
root, but stuff happens.
I guess the thing to do would be to manually re-populate /lib and /lib/bin
with whatever is supposed to be in there, which is something I think you are
more familiar with. Just a bunch of adds and commits.
I can assist if you tell me what the contents of that directory must be.
I suspect this also happened with the two subdirs in the /viewer directory:
the Java files directly inside /viewer are present, but the /images and
/resources subdirs are empty in the release-0-13-0 branch. I'm going to
remedy this particular problem before the end of the day.
Arved
At 09:29 AM 5/18/00 +0200, Fotis Jannidis wrote:
>Arved:
>
>I did try to checkout the new branch: I got the subdirs /src and /docs,
but not /lib - so
>build fails.
>I am using wincvs 1.1 and it sent the following line to the server:
>
>cvs checkout -r release-0-13-0 xml-fop
>
>Any ideas?
>
>Fotis
>
>
>
Re: New CVS Branch
Posted by Fotis Jannidis <Fo...@lrz.uni-muenchen.de>.
Arved:
I did try to checkout the new branch: I got the subdirs /src and /docs, but not /lib - so
build fails.
I am using wincvs 1.1 and it sent the following line to the server:
cvs checkout -r release-0-13-0 xml-fop
Any ideas?
Fotis
RE: New CVS Branch
Posted by Dave Pawson <da...@virgin.net>.
P.S. At some point, roughly a week from now, but maybe later
(who knows),
we'll tag the files as they are on the maintenance
(release-0-13-0) branch,
and use the files in that state for producing an interim FOP JAR.
Yes please :-)
DaveP
Re: New CVS Branch
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
It's also worth adding that I did all this on Linux, where I have things set
up for committer status. I have further checked on Windows, where I use
WinCVS 1.1, as an anonymous CVS user, and I successfully updated my working
copy over to the release-0-13-0 branch. So I think things are OK.
Arved
At 11:36 PM 5/17/00 -0300, Arved Sandstrom wrote:
>OK, as we discussed, I created a new branch that is intended to serve as the
>basis for any intermediate efforts leading to the shortly forthcoming 0.13.0
>interim release.
>
>Here's what I did:
>
>(1) Updated my working copy;
>
>(2) Created the new branch with
>
> cvs tag -b release-0-13-0
>
>I also then immediately created a new directory elsewhere, and did a
>
> cvs checkout -r release-0-13-0 xml-fop
>
>into that directory. My reason for doing so was to verify the preceding
>operation, and to give myself one working copy (the original) which is on
>the main trunk, intended for the FOP 1.0 efforts, and one separate working
>copy which is on the branch, so that any commits I do in _that_ working copy
>will only affect the maintenance release.
>
>You don't have to do it this way: if you'd like to temporarily switch your
>working copy over to the new branch then do
>
> cvs update -r release-0-13-0
>
>in your working copy.
>
>I'd appreciate it if committers/developers check all of this out. Most of
>CVS is new to me, too.
>
>If you don't do anything different whatsoever, and continue business as
>usual, your commits should affect the main trunk, that is, the code intended
>for the FOP 1.0 release.
>
>Please let me know if you think anything screwed up. Thank you.
>
>Arved Sandstrom
>
>P.S. At some point, roughly a week from now, but maybe later (who knows),
>we'll tag the files as they are on the maintenance (release-0-13-0) branch,
>and use the files in that state for producing an interim FOP JAR.
>
>
>