Fwd: Re: [MP-d] Parallel branches for existing derivations

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

-----BEGIN PGP SIGNED MESSAGE-----

Hi!

Peter wrote a mail to me personally stating the following mail does
not geht through to this list. He tried several times without any
effect :-( .

I'm forwarding it here so it is at least known. If this problem
persists I think I need to contact the SourceForge staff. I checked
the settings for the mailing list and I can's see a reason for this
behaviour on this side.

						Gr=FC=DFe

						Stefan

- ------- Forwarded Message

Hi together,

as far as I understood the information and suggestions given by Stefan ab=
out
opening Comic-specific things, e.g. opening a branch: I agree.

One thing: I'm currently busy with building up a new Comic testbed for th=
e
next demonstrator integration (by "merging" the most recent SmartKom test=
bed
5.1 and the Comic specific things). My delivery deadline is October,
2. Therefore I'd like to postpone all comic-specific multiplatform activi=
ties
after my deadline. Is that ok for everybody or are there any objections ?

Best,

Peter

Stefan Merten writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 >=20
 > Hi all!
 >=20
 > 4 days ago Stefan Merten wrote:
 > ...
 > > * Import your sources to your branch.
 > >=20
 > >   Ahm - I need to think about how to do that. This is a critical
 > >   operation and it can make the repository quite ugly if done wrong.
 > >=20
 > >   I'll experiment a bit here and tell you about what I think is
 > >   useful.
 >=20
 > I thought about it and noticed that `lcvs' needs a change (I said that
 > here already - right?). In the brand new version 1.5.5 I now added a
 > feature which allows import to a new vendor branch. I did not need
 > this before. Please download from
 >=20
 > 	http://www.merten-home.de/FreeSoftware/lcvs/
 >=20
 > I played around with importing to various vendor branches and found we
 > need to have explicit branch revision numbers for the various vendor
 > branches. They must be given to the `-b' option.
 >=20
 > At the moment we are expecting one branch for Comic so I suggest this
 > is
 >=20
 > 	1.1.2
 >=20
 > while we expect at least one branch from Philips. So I suggest using
 >=20
 > 	1.1.3
 >=20
 > (and upward) for the Philips vendor branches.
 >=20
 > Ok. So now we have laid the foundations for the imports.
 >=20
 > Now it is time to tell you something about the module system I
 > employed (and `lcvs' needs). The basic idea is that each package gets
 > an own (CVS) module name in the repository. I.e. it has an entry in
 > `CVSROOT/modules'. You don't need to care about creating this entry
 > because it is already there and `lcvs' is caring about it anyway.
 >=20
 > The adavantage of these modules is that all packages are independent
 > from each other. You can check out one module and work with that
 > without needing the whole source tree for Multiplatform.
 >=20
 > You may check which modules exist currently by
 >=20
 > 	lcvs -d AC...@cv...:/cvsroot/multiplatform checkout -=
c
 >=20
 > The left column shows the module name while the right column shows the
 > location of the module in the CVS repository. You'll notice that the
 > module names are just the basenames of the respective directories. One
 > should not make things more complicated than necessary - but also not
 > less ;-) .
 >=20
 > If you import your version of the sources you should do this on a
 > module by module basis. For example Peter may start with
 >=20
 > 	cd source/opt/base
 > 	lcvs -d pp...@cv...:/cvsroot/multiplatform -m 'Import=
ed from Comic.' -b 1.1.2 source/opt/base comic base
 >=20
 > Again please double check that this does not introduce unwanted files
 > as I tried to explain in my last mail. If you are in doubt I am ready
 > to help in any thinkable way.
 >=20
 > BTW: Once you get an checked out version of the sources you don't need
 > `-d AC...@cv...:/cvsroot/multiplatform' any more
 > because this is recorded in the local CVS administrative files then.
 >=20
 > BTW: You don't need to worry about the module named `top'. I added
 > that to hold some files which should be in the top level directory of
 > the source tree.
 >=20
 > Ok. I think this is it. Let's hope that Thomas gets his `ssh' through
 > to SourceForge. Please tell me of any progress.
 >=20
 > Ah, one more thought. It is possible to employ means to get noticed
 > when the repository is changed. I did not employ anything yet. I'll
 > think about that.
 >=20
 >=20
 > 						Gr=FC=DFe
 >=20
 > 						Stefan
 >=20
 > -----BEGIN PGP SIGNATURE-----
 > Version: 2.6.2
 > Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
 >=20
 > iQCVAgUBP3BvZQnTZgC3zSk5AQFLZAQAgSuLiCJPR6AHkqlrW1ERBOgYzblP7tRA
 > VihyMdH4g5aACbzwCFH6A7fDd4fenfSrwREhhlyiOs5Kjm3R6ExkqjgATTxC45q7
 > 7I9stCrOFSg9dkjoLUrxPbvYijl7FwBz64UWaT9lHXtVK37U98K3KyXqktjTQT+T
 > QUqsrVyLSjs=3D
 > =3Dvgcs
 > -----END PGP SIGNATURE-----
 >=20
 >=20
 > -------------------------------------------------------
 > This sf.net email is sponsored by:ThinkGeek
 > Welcome to geek heaven.
 > http://thinkgeek.com/sf
 > _______________________________________________
 > multiplatform-devel mailing list
 > mul...@li...
 > https://lists.sourceforge.net/lists/listinfo/multiplatform-devel
 >=20

- ------- End of Forwarded Message

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAgUBP3gDLQnTZgC3zSk5AQE/BAP9G55CBb+Q+7GA59FeRIsOhWmU4DKzAt6V
4Z4GFCJJChzxOvNTbYd7hzL7YvfCfhEfW8APCGJ0FIB9FgVVlfBoXcuD6NCDsh9+
7s3tA1XbwOzh2C7BNxNYGxXJEHCdWjPMDoUMX9JHBwlf4w6QB2sPbuBxsjNiKQHb
UlRjQW+aTEY=3D
=3DwKMI
-----END PGP SIGNATURE-----