| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1371.1 | Re: links and Ode/rcs | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Wed Mar 29 1995 12:33 | 63 |
| Date Of Receipt: 29-MAR-1995 11:01:42.50
From: SMURF::ALPHA::"[email protected]" "29-Mar-1995 1100"
To: [email protected]
CC: [email protected]
Subj: Re: links and Ode/rcs
|
| Last week I sent email concerning using links to allow files(and underlying
| source control) to exist in more than one location within a directory
| structure. I wonder if this message was lost, because I had not had
| a response.
I never saw it.
| Anyway, I have determined the following:
|
| 1) mksubmit will not work if the rcs tree has symbolic links in the rcs tree
| 2) bci, and other rcs commands, by design breaks hard links
|
| The only solution I see at this point is to create my rcs tree with hard
| links so that mksubmit can be used to create the initial submit tree and then
| recreate the rcs tree with symbolic links... I am concerned that I have
| overlooked something.
|
Currently links to files in RCS does not work. Links to directories does. If
you can include the whole subdir, you're all set.
|
| So, what is one to do when one version of the product has one tree structure
| and the next version of the product has a different tree structure and
| development needs to progress on both versions concurrently.
|
| This is the case with X between gold and platinum. This problem seems to
| have been solved. The Open3d group needs to replicate this work.
This happened by moving most of the Platinum (R6) based work down a level in
RCS. Code exists in src/xc (consortium) src/adobe, src/gnu, src/Tcl etc.
The only exception is the server stuff which uses a symlink in RCS to resolve
the path change. CDE has it's own RCS pool because they felt they were unable
to move down a level.
|
|
|
| A second, though related, issue, concerns the snapshot files. Once the
| two trees are created, submissions to one tree only updated the snapshot
| file in that tree. Is it necessary to mksnapshot before creating a backing
| tree to correct this problem, or is there a simpler way to generate a correct
| snapshot file?
|
I don't understand this question at all. If you make two submit trees with a
common RCS pool, but only submit to one of them, did you expect the SNAPSHOT
in the other one to get updated??
-Grant
|
| 1371.2 | Re: links and Ode/rcs | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Wed Mar 29 1995 13:35 | 39 |
| Date Of Receipt: 29-MAR-1995 12:33:43.43
From: SMURF::WASTED::"[email protected]" "29-Mar-1995 1231"
To: "Grant Van Dyck" <[email protected]>
CC: [email protected]
Subj: Re: links and Ode/rcs
>I don't understand this question at all. If you make two submit trees with a
>common RCS pool, but only submit to one of them, did you expect the SNAPSHOT
>in the other one to get updated??
I thought I was pretty clear on that. Obviously, if there are two different
submit trees then only one submit tree is update on a submit. The question
was what is the simplest(fastest) way to generate a correct snapshot file, when
the underlaying rcs files may have been updated through it's other path?
I know mksnapshot will work, it is extremely slow. It seems to take 2-3 hours
to generate a new snapshot for our existing ML(mainline) pool. This is a
very big delay in the build process. I was hoping that you folks had some
nifty little tool that updated the snapshot file.
ALSO, you stated that symlinks to directories works. mksubmit did not
work with symlinks to directories. That was the first thing that I tried.
I ended up with a submit tree with no files in it and src/FILES_NOT_FOUND
listed all of the symlinks to directories.
It almost seems to me that you folks do not use mksubmit and generate your
submit trees by hand. I would guess that I could have edit'ed a snapshot
file and then ran mkback to generate the submit tree. Is that what was
done to create x11r6 submit tree?
thanks
Martin
|
| 1371.3 | Re: links and Ode/rcs | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Wed Mar 29 1995 14:38 | 53 |
| Date Of Receipt: 29-MAR-1995 13:02:33.41
From: SMURF::ALPHA::"[email protected]" "29-Mar-1995 1301"
To: [email protected]
CC: [email protected]
Subj: Re: links and Ode/rcs
| I thought I was pretty clear on that. Obviously, if there are two different
| submit trees then only one submit tree is update on a submit. The question
| was what is the simplest(fastest) way to generate a correct snapshot file, wh
en
| the underlaying rcs files may have been updated through it's other path?
|
| I know mksnapshot will work, it is extremely slow. It seems to take 2-3 hour
s
| to generate a new snapshot for our existing ML(mainline) pool. This is a
| very big delay in the build process. I was hoping that you folks had some
| nifty little tool that updated the snapshot file.
|
We don't use mksnapshot, or mkback, and only rarely mksubmit. Almost all the
submit trees are shared sandboxes, backed by other fully populated (baselevel)
trees. The only files in them are files that have actually been submitted
there, the rest are symlinks to the pools backingtree. Therefore the only
files in the SNAPSHOT are the ones that bsubmit put there when files were
submitted.
When the build of that pool is complete and it propagated to nightly (fully
populated), then the SNAPSHOT file becomes the SNAPSHOT of the backing pool,
OVERWRITTEN with the actual submissions to that pool.
| ALSO, you stated that symlinks to directories works. mksubmit did not
| work with symlinks to directories. That was the first thing that I tried.
| I ended up with a submit tree with no files in it and src/FILES_NOT_FOUND
| listed all of the symlinks to directories.
|
|
| It almost seems to me that you folks do not use mksubmit and generate your
| submit trees by hand. I would guess that I could have edit'ed a snapshot
| file and then ran mkback to generate the submit tree. Is that what was
| done to create x11r6 submit tree?
Yes, since we don't use mksubmit, we haven't stumbled on that. I'd file a PTT
(gen-ptt) against mksubmit so that support for this feature might find it's
way into ODE III.
-Grant
|
| 1371.4 | Re: links and Ode/rcs | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Wed Mar 29 1995 17:45 | 28 |
| Date Of Receipt: 29-MAR-1995 15:56:35.44
From: SMURF::WASTED::"[email protected]" "29-Mar-1995 1554"
To: "Grant Van Dyck" <[email protected]>
CC: [email protected]
Subj: Re: links and Ode/rcs
>We don't use mksnapshot, or mkback, and only rarely mksubmit. Almost all the
>submit trees are shared sandboxes, backed by other fully populated (baselevel)
>trees. The only files in them are files that have actually been submitted
>there, the rest are symlinks to the pools backingtree. Therefore the only
>files in the SNAPSHOT are the ones that bsubmit put there when files were
>submitted.
Somehow, I must be missing the significance of "submit trees are shared sandboxes"
What does this mean?
>When the build of that pool is complete and it propagated to nightly (fully
>populated), then the SNAPSHOT file becomes the SNAPSHOT of the backing pool,
>OVERWRITTEN with the actual submissions to that pool.
When files from a build are moved into the nightly build, how is the SNAPSHOT
file in the nightly tree updated?
Also, how does one initialize the new build area? Is it just a mklinks to
the shared sandbox and creating an empty SNAPSHOT file?
Martin
|