Home » Eclipse Projects » Orbit » orbit cvs repository
|
Re: orbit cvs repository [message #8954 is a reply to message #8888] |
Fri, 05 January 2007 16:37 |
Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
Eugene Kuleshov wrote:
> Hi,
>
> I've been looking trough Orbit's CVS repository and wondering what was
> the reasons for chosen structures? It doesn't seem like such structure
> supported well by Eclipse CVS support, and hence won't scale very well
> in a long run.
>
> Attached screenshot of the CVS Repository view shows branches for two
> bundles lucene (1.4.3 and 1.9.1) and oro (2.0.8). Isn't it confusing to
> see the orbit project and all bundle siblings under every
> version/branch? Basically all versions are going to be flattened in that
> list and with large number of bundles it will be very hard to navigate
> trough such structures.
The FAQ
http://wiki.eclipse.org/index.php/Orbit_Faq#How_do_I_work_wi th_a_bundle_in_Orbit
describes how best to manage the CVS code. This approach was decided on
in the first Orbit conference call. It is believed to be simpler and
more in keeping with the current practices than having CVS folders that
incorporate version numbers etc.
> I also wonder why bundle classes has to be unzipped instead of using
> original jars? With unzipped classes it will be also hard to track down
> to what release of the original jar these classes came from. Not to say
> that we can't do integrity checking using checksums published by jar
> vendors at the release times.
As for exploding the jars, this facilitates the direct use of these
projects in the Eclipse workspace as well as direct building of the
project to create bundles with the code, metadata and additional
material needed. In general we have found that original JARs are of
very little use as they often contain extra stuff (e.g., source) and are
not particularly well versioned/named. We certainly could (and perhaps
should) adopt the practice of including the original JAR in the project
for traceability but that JAR should not be confused with anything that
should be used for building or execution.
HTH
Jeff
|
|
|
Re: orbit cvs repository [message #8993 is a reply to message #8954] |
Fri, 05 January 2007 17:00 |
Eugene Kuleshov Messages: 504 Registered: July 2009 |
Senior Member |
|
|
Jeff McAffer wrote:
> The FAQ
> http://wiki.eclipse.org/index.php/Orbit_Faq#How_do_I_work_wi th_a_bundle_in_Orbit
>
> describes how best to manage the CVS code. This approach was decided
> on in the first Orbit conference call. It is believed to be simpler
> and more in keeping with the current practices than having CVS folders
> that incorporate version numbers etc.
Don't you think it is obscure?
How user would know what branches/versions are available for given bundle?
I not quite understand why do you need branches. Those bundles
supposed to be pretty much static, because it is a released artifacts,
they not suppose to evolve.
So, it seem more naturally to use tags or put versions into the folder
names. The latter has its own benefits, because it can allow non-CVS
based interaction. E.g. is somebody would want to have private
"Orbit"-like repository.
Another advantage of adding versions into project folders (and project
names) is that user would be able to have more then one version checked
out in the same workspace. I think that is really huge limitation.
>> I also wonder why bundle classes has to be unzipped instead of
>> using original jars? With unzipped classes it will be also hard to
>> track down to what release of the original jar these classes came
>> from. Not to say that we can't do integrity checking using checksums
>> published by jar vendors at the release times.
> As for exploding the jars, this facilitates the direct use of these
> projects in the Eclipse workspace as well as direct building of the
> project to create bundles with the code, metadata and additional
> material needed.
I am not sure why you need to expand the class files in order to
generate metadata? PDE and OSGi allows to create a "wrapper" bundles
that could use original jars in their own classpath (I believe ant,
lucene and junit plugins included into the JDT/Platfrom are packaged
like that). Is there any problem with that?
Even if Orbit's build need individual classes to do some magic, the
build could explode jars to some temporary location during the build...
> In general we have found that original JARs are of very little use as
> they often contain extra stuff (e.g., source) and are not particularly
> well versioned/named. We certainly could (and perhaps should) adopt
> the practice of including the original JAR in the project for
> traceability but that JAR should not be confused with anything that
> should be used for building or execution.
I am talking about the jars built by the project owners and you
probably referring to the binary builds (i.e. zip or tar.gz archive with
the jar file and other stuff in it). The former is deployed to Maven's
central repository for most of the popular open source projects and its
checksum is available from there.
So, it is really bad idea to expand those jars and commit individual
classes into Orbit's own CVS, at least because it will make integrity
checking very hard. I.e. CVS checkout is not an atomic operation and it
can fail anywhere in the middle of checkout. Note that CVS access to
Eclipse repository is super fast not to everybody.
regards,
Eugene
|
|
|
Re: orbit cvs repository [message #10505 is a reply to message #8993] |
Sun, 23 September 2007 10:11 |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Eugene Kuleshov schrieb:
> Jeff McAffer wrote:
>> The FAQ
>> http://wiki.eclipse.org/index.php/Orbit_Faq#How_do_I_work_wi th_a_bundle_in_Orbit
>>
>> describes how best to manage the CVS code. This approach was decided
>> on in the first Orbit conference call. It is believed to be simpler
>> and more in keeping with the current practices than having CVS
>> folders that incorporate version numbers etc.
> Don't you think it is obscure?
> How user would know what branches/versions are available for given
> bundle?
>
> I not quite understand why do you need branches. Those bundles
> supposed to be pretty much static, because it is a released artifacts,
> they not suppose to evolve.
> So, it seem more naturally to use tags or put versions into the
> folder names. The latter has its own benefits, because it can allow
> non-CVS based interaction. E.g. is somebody would want to have private
> "Orbit"-like repository.
>
> Another advantage of adding versions into project folders (and
> project names) is that user would be able to have more then one
> version checked out in the same workspace. I think that is really huge
> limitation.
+1
Is there a chance that the original decision that Jeff refers to is
reconsidered?
I also plan to make Orbit contributions but this makes me think twice.
Cheers
/Eike
|
|
|
Re: orbit cvs repository [message #10538 is a reply to message #10505] |
Sun, 23 September 2007 12:24 |
|
Eike Stepper wrote:
> Eugene Kuleshov schrieb:
>> Jeff McAffer wrote:
>>> The FAQ
>>> http://wiki.eclipse.org/index.php/Orbit_Faq#How_do_I_work_wi th_a_bundle_in_Orbit
>>>
>>> describes how best to manage the CVS code. This approach was decided
>>> on in the first Orbit conference call. It is believed to be simpler
>>> and more in keeping with the current practices than having CVS
>>> folders that incorporate version numbers etc.
>> Don't you think it is obscure?
>> How user would know what branches/versions are available for given
>> bundle?
>>
>> I not quite understand why do you need branches. Those bundles
>> supposed to be pretty much static, because it is a released artifacts,
>> they not suppose to evolve.
>> So, it seem more naturally to use tags or put versions into the
>> folder names. The latter has its own benefits, because it can allow
>> non-CVS based interaction. E.g. is somebody would want to have private
>> "Orbit"-like repository.
>>
>> Another advantage of adding versions into project folders (and
>> project names) is that user would be able to have more then one
>> version checked out in the same workspace. I think that is really huge
>> limitation.
> +1
> Is there a chance that the original decision that Jeff refers to is
> reconsidered?
> I also plan to make Orbit contributions but this makes me think twice.
>
Why do you need versions in project folders in order to check out
different versionsinto your workspace? Why not just check out different
tags into different projects?
Regards,
Thomas Hallgren
|
|
|
Re: orbit cvs repository [message #10569 is a reply to message #10538] |
Sun, 23 September 2007 14:45 |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Thomas Hallgren schrieb:
> Eike Stepper wrote:
>> Eugene Kuleshov schrieb:
>>> Jeff McAffer wrote:
>>>> The FAQ
>>>> http://wiki.eclipse.org/index.php/Orbit_Faq#How_do_I_work_wi th_a_bundle_in_Orbit
>>>>
>>>> describes how best to manage the CVS code. This approach was
>>>> decided on in the first Orbit conference call. It is believed to
>>>> be simpler and more in keeping with the current practices than
>>>> having CVS folders that incorporate version numbers etc.
>>> Don't you think it is obscure?
>>> How user would know what branches/versions are available for given
>>> bundle?
>>>
>>> I not quite understand why do you need branches. Those bundles
>>> supposed to be pretty much static, because it is a released
>>> artifacts, they not suppose to evolve.
>>> So, it seem more naturally to use tags or put versions into the
>>> folder names. The latter has its own benefits, because it can allow
>>> non-CVS based interaction. E.g. is somebody would want to have
>>> private "Orbit"-like repository.
>>>
>>> Another advantage of adding versions into project folders (and
>>> project names) is that user would be able to have more then one
>>> version checked out in the same workspace. I think that is really
>>> huge limitation.
>> +1
>> Is there a chance that the original decision that Jeff refers to is
>> reconsidered?
>> I also plan to make Orbit contributions but this makes me think twice.
>>
>
> Why do you need versions in project folders in order to check out
> different versionsinto your workspace? Why not just check out
> different tags into different projects?
I don't need them in the sense that I'd be unable to work with them
otherwise.
I just agree with Eugene in that it would be much simpler to have them
without branches.
To repeat his arguments:
1) Eclipse CVS client is not particularly well suited to work with branches
2) The projects we talk about in the context of Orbit are somewhat
immutable once they're released, i.e. they don't contain sources with
active development.
3) If you need multiple versions of the same bundle at the same time in
your worksace you'd have to switch to the versioned project name anyway.
It would be much simpler to work with them if they are listed under HEAD
side by side.
Do you really disagree with that?
Cheers
/Eike
|
|
|
Re: orbit cvs repository [message #10602 is a reply to message #10569] |
Mon, 24 September 2007 06:46 |
|
Eike Stepper wrote:
> Thomas Hallgren schrieb:
>> Why do you need versions in project folders in order to check out
>> different versionsinto your workspace? Why not just check out
>> different tags into different projects?
> I don't need them in the sense that I'd be unable to work with them
> otherwise.
> I just agree with Eugene in that it would be much simpler to have them
> without branches.
>
> To repeat his arguments:
> 1) Eclipse CVS client is not particularly well suited to work with branches
> 2) The projects we talk about in the context of Orbit are somewhat
> immutable once they're released, i.e. they don't contain sources with
> active development.
> 3) If you need multiple versions of the same bundle at the same time in
> your worksace you'd have to switch to the versioned project name anyway.
>
> It would be much simpler to work with them if they are listed under HEAD
> side by side.
> Do you really disagree with that?
To some extent yes, I do. What you really do is mirror source that is
maintained in some other repository. If you did treat Orbit as a mirror
and used tags (I'm not in favor of CVS branches either), you'd get the
benefit of source history. IMO, imperative when you do impact analysis
when incorporating a new version.
Another, perhaps more biased reason is that some tools out there that
are capable of transitive resolution and check-out, will not expect a
cvs repository to be used this way. It defeats the reason for using a
repository capable of versioning. Why use CVS in the first place? Why
not just import a zipped bundle that contains source in that case?
- thomas
|
|
|
Re: orbit cvs repository [message #10635 is a reply to message #10602] |
Mon, 24 September 2007 07:38 |
|
Sorry, just read up on the Orbit structures. I took one thing for
granted, namely that the CVS was used to maintain the source of the
bundles. Apparently that's not the case at all. Which makes me wonder;
why use CVS in the first place? What benefits does it bring that the
download page doesn't?
A more natural way of doing it (to me that is) would be to explode the
source into CVS and maintain (and build from) that. Either that, or as I
mentioned earlier, simply import the project from a zipped archive (with
or without source).
- thomas
Thomas Hallgren wrote:
> Eike Stepper wrote:
>> Thomas Hallgren schrieb:
>>> Why do you need versions in project folders in order to check out
>>> different versionsinto your workspace? Why not just check out
>>> different tags into different projects?
>> I don't need them in the sense that I'd be unable to work with them
>> otherwise.
>> I just agree with Eugene in that it would be much simpler to have them
>> without branches.
>>
>> To repeat his arguments:
>> 1) Eclipse CVS client is not particularly well suited to work with
>> branches
>> 2) The projects we talk about in the context of Orbit are somewhat
>> immutable once they're released, i.e. they don't contain sources with
>> active development.
>> 3) If you need multiple versions of the same bundle at the same time
>> in your worksace you'd have to switch to the versioned project name
>> anyway.
>>
>> It would be much simpler to work with them if they are listed under
>> HEAD side by side.
>> Do you really disagree with that?
>
> To some extent yes, I do. What you really do is mirror source that is
> maintained in some other repository. If you did treat Orbit as a mirror
> and used tags (I'm not in favor of CVS branches either), you'd get the
> benefit of source history. IMO, imperative when you do impact analysis
> when incorporating a new version.
>
> Another, perhaps more biased reason is that some tools out there that
> are capable of transitive resolution and check-out, will not expect a
> cvs repository to be used this way. It defeats the reason for using a
> repository capable of versioning. Why use CVS in the first place? Why
> not just import a zipped bundle that contains source in that case?
>
> - thomas
|
|
|
Re: orbit cvs repository [message #10667 is a reply to message #10635] |
Mon, 24 September 2007 07:41 |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Thomas Hallgren schrieb:
> Sorry, just read up on the Orbit structures. I took one thing for
> granted, namely that the CVS was used to maintain the source of the
> bundles. Apparently that's not the case at all. Which makes me wonder;
> why use CVS in the first place? What benefits does it bring that the
> download page doesn't?
Good question. I guess it's due to requirements of the PDE build.
> A more natural way of doing it (to me that is) would be to explode the
> source into CVS and maintain (and build from) that. Either that, or as
> I mentioned earlier, simply import the project from a zipped archive
> (with or without source).
>
> - thomas
>
>
> Thomas Hallgren wrote:
>> Eike Stepper wrote:
>>> Thomas Hallgren schrieb:
>>>> Why do you need versions in project folders in order to check out
>>>> different versionsinto your workspace? Why not just check out
>>>> different tags into different projects?
>>> I don't need them in the sense that I'd be unable to work with them
>>> otherwise.
>>> I just agree with Eugene in that it would be much simpler to have
>>> them without branches.
>>>
>>> To repeat his arguments:
>>> 1) Eclipse CVS client is not particularly well suited to work with
>>> branches
>>> 2) The projects we talk about in the context of Orbit are somewhat
>>> immutable once they're released, i.e. they don't contain sources
>>> with active development.
>>> 3) If you need multiple versions of the same bundle at the same time
>>> in your worksace you'd have to switch to the versioned project name
>>> anyway.
>>>
>>> It would be much simpler to work with them if they are listed under
>>> HEAD side by side.
>>> Do you really disagree with that?
>>
>> To some extent yes, I do. What you really do is mirror source that is
>> maintained in some other repository. If you did treat Orbit as a
>> mirror and used tags (I'm not in favor of CVS branches either), you'd
>> get the benefit of source history. IMO, imperative when you do impact
>> analysis when incorporating a new version.
>>
>> Another, perhaps more biased reason is that some tools out there that
>> are capable of transitive resolution and check-out, will not expect a
>> cvs repository to be used this way. It defeats the reason for using a
>> repository capable of versioning. Why use CVS in the first place? Why
>> not just import a zipped bundle that contains source in that case?
>>
>> - thomas
|
|
| |
Re: orbit cvs repository [message #562283 is a reply to message #8954] |
Fri, 05 January 2007 17:00 |
Eugene Kuleshov Messages: 504 Registered: July 2009 |
Senior Member |
|
|
Jeff McAffer wrote:
> The FAQ
> http://wiki.eclipse.org/index.php/Orbit_Faq#How_do_I_work_wi th_a_bundle_in_Orbit
>
> describes how best to manage the CVS code. This approach was decided
> on in the first Orbit conference call. It is believed to be simpler
> and more in keeping with the current practices than having CVS folders
> that incorporate version numbers etc.
Don't you think it is obscure?
How user would know what branches/versions are available for given bundle?
I not quite understand why do you need branches. Those bundles
supposed to be pretty much static, because it is a released artifacts,
they not suppose to evolve.
So, it seem more naturally to use tags or put versions into the folder
names. The latter has its own benefits, because it can allow non-CVS
based interaction. E.g. is somebody would want to have private
"Orbit"-like repository.
Another advantage of adding versions into project folders (and project
names) is that user would be able to have more then one version checked
out in the same workspace. I think that is really huge limitation.
>> I also wonder why bundle classes has to be unzipped instead of
>> using original jars? With unzipped classes it will be also hard to
>> track down to what release of the original jar these classes came
>> from. Not to say that we can't do integrity checking using checksums
>> published by jar vendors at the release times.
> As for exploding the jars, this facilitates the direct use of these
> projects in the Eclipse workspace as well as direct building of the
> project to create bundles with the code, metadata and additional
> material needed.
I am not sure why you need to expand the class files in order to
generate metadata? PDE and OSGi allows to create a "wrapper" bundles
that could use original jars in their own classpath (I believe ant,
lucene and junit plugins included into the JDT/Platfrom are packaged
like that). Is there any problem with that?
Even if Orbit's build need individual classes to do some magic, the
build could explode jars to some temporary location during the build...
> In general we have found that original JARs are of very little use as
> they often contain extra stuff (e.g., source) and are not particularly
> well versioned/named. We certainly could (and perhaps should) adopt
> the practice of including the original JAR in the project for
> traceability but that JAR should not be confused with anything that
> should be used for building or execution.
I am talking about the jars built by the project owners and you
probably referring to the binary builds (i.e. zip or tar.gz archive with
the jar file and other stuff in it). The former is deployed to Maven's
central repository for most of the popular open source projects and its
checksum is available from there.
So, it is really bad idea to expand those jars and commit individual
classes into Orbit's own CVS, at least because it will make integrity
checking very hard. I.e. CVS checkout is not an atomic operation and it
can fail anywhere in the middle of checkout. Note that CVS access to
Eclipse repository is super fast not to everybody.
regards,
Eugene
|
|
|
Re: orbit cvs repository [message #562845 is a reply to message #8993] |
Sun, 23 September 2007 10:11 |
|
Eugene Kuleshov schrieb:
> Jeff McAffer wrote:
>> The FAQ
>> http://wiki.eclipse.org/index.php/Orbit_Faq#How_do_I_work_wi th_a_bundle_in_Orbit
>>
>> describes how best to manage the CVS code. This approach was decided
>> on in the first Orbit conference call. It is believed to be simpler
>> and more in keeping with the current practices than having CVS
>> folders that incorporate version numbers etc.
> Don't you think it is obscure?
> How user would know what branches/versions are available for given
> bundle?
>
> I not quite understand why do you need branches. Those bundles
> supposed to be pretty much static, because it is a released artifacts,
> they not suppose to evolve.
> So, it seem more naturally to use tags or put versions into the
> folder names. The latter has its own benefits, because it can allow
> non-CVS based interaction. E.g. is somebody would want to have private
> "Orbit"-like repository.
>
> Another advantage of adding versions into project folders (and
> project names) is that user would be able to have more then one
> version checked out in the same workspace. I think that is really huge
> limitation.
+1
Is there a chance that the original decision that Jeff refers to is
reconsidered?
I also plan to make Orbit contributions but this makes me think twice.
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: orbit cvs repository [message #562871 is a reply to message #10505] |
Sun, 23 September 2007 12:24 |
|
Eike Stepper wrote:
> Eugene Kuleshov schrieb:
>> Jeff McAffer wrote:
>>> The FAQ
>>> http://wiki.eclipse.org/index.php/Orbit_Faq#How_do_I_work_wi th_a_bundle_in_Orbit
>>>
>>> describes how best to manage the CVS code. This approach was decided
>>> on in the first Orbit conference call. It is believed to be simpler
>>> and more in keeping with the current practices than having CVS
>>> folders that incorporate version numbers etc.
>> Don't you think it is obscure?
>> How user would know what branches/versions are available for given
>> bundle?
>>
>> I not quite understand why do you need branches. Those bundles
>> supposed to be pretty much static, because it is a released artifacts,
>> they not suppose to evolve.
>> So, it seem more naturally to use tags or put versions into the
>> folder names. The latter has its own benefits, because it can allow
>> non-CVS based interaction. E.g. is somebody would want to have private
>> "Orbit"-like repository.
>>
>> Another advantage of adding versions into project folders (and
>> project names) is that user would be able to have more then one
>> version checked out in the same workspace. I think that is really huge
>> limitation.
> +1
> Is there a chance that the original decision that Jeff refers to is
> reconsidered?
> I also plan to make Orbit contributions but this makes me think twice.
>
Why do you need versions in project folders in order to check out
different versionsinto your workspace? Why not just check out different
tags into different projects?
Regards,
Thomas Hallgren
|
|
|
Re: orbit cvs repository [message #562898 is a reply to message #10538] |
Sun, 23 September 2007 14:45 |
|
Thomas Hallgren schrieb:
> Eike Stepper wrote:
>> Eugene Kuleshov schrieb:
>>> Jeff McAffer wrote:
>>>> The FAQ
>>>> http://wiki.eclipse.org/index.php/Orbit_Faq#How_do_I_work_wi th_a_bundle_in_Orbit
>>>>
>>>> describes how best to manage the CVS code. This approach was
>>>> decided on in the first Orbit conference call. It is believed to
>>>> be simpler and more in keeping with the current practices than
>>>> having CVS folders that incorporate version numbers etc.
>>> Don't you think it is obscure?
>>> How user would know what branches/versions are available for given
>>> bundle?
>>>
>>> I not quite understand why do you need branches. Those bundles
>>> supposed to be pretty much static, because it is a released
>>> artifacts, they not suppose to evolve.
>>> So, it seem more naturally to use tags or put versions into the
>>> folder names. The latter has its own benefits, because it can allow
>>> non-CVS based interaction. E.g. is somebody would want to have
>>> private "Orbit"-like repository.
>>>
>>> Another advantage of adding versions into project folders (and
>>> project names) is that user would be able to have more then one
>>> version checked out in the same workspace. I think that is really
>>> huge limitation.
>> +1
>> Is there a chance that the original decision that Jeff refers to is
>> reconsidered?
>> I also plan to make Orbit contributions but this makes me think twice.
>>
>
> Why do you need versions in project folders in order to check out
> different versionsinto your workspace? Why not just check out
> different tags into different projects?
I don't need them in the sense that I'd be unable to work with them
otherwise.
I just agree with Eugene in that it would be much simpler to have them
without branches.
To repeat his arguments:
1) Eclipse CVS client is not particularly well suited to work with branches
2) The projects we talk about in the context of Orbit are somewhat
immutable once they're released, i.e. they don't contain sources with
active development.
3) If you need multiple versions of the same bundle at the same time in
your worksace you'd have to switch to the versioned project name anyway.
It would be much simpler to work with them if they are listed under HEAD
side by side.
Do you really disagree with that?
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: orbit cvs repository [message #562920 is a reply to message #10569] |
Mon, 24 September 2007 06:46 |
|
Eike Stepper wrote:
> Thomas Hallgren schrieb:
>> Why do you need versions in project folders in order to check out
>> different versionsinto your workspace? Why not just check out
>> different tags into different projects?
> I don't need them in the sense that I'd be unable to work with them
> otherwise.
> I just agree with Eugene in that it would be much simpler to have them
> without branches.
>
> To repeat his arguments:
> 1) Eclipse CVS client is not particularly well suited to work with branches
> 2) The projects we talk about in the context of Orbit are somewhat
> immutable once they're released, i.e. they don't contain sources with
> active development.
> 3) If you need multiple versions of the same bundle at the same time in
> your worksace you'd have to switch to the versioned project name anyway.
>
> It would be much simpler to work with them if they are listed under HEAD
> side by side.
> Do you really disagree with that?
To some extent yes, I do. What you really do is mirror source that is
maintained in some other repository. If you did treat Orbit as a mirror
and used tags (I'm not in favor of CVS branches either), you'd get the
benefit of source history. IMO, imperative when you do impact analysis
when incorporating a new version.
Another, perhaps more biased reason is that some tools out there that
are capable of transitive resolution and check-out, will not expect a
cvs repository to be used this way. It defeats the reason for using a
repository capable of versioning. Why use CVS in the first place? Why
not just import a zipped bundle that contains source in that case?
- thomas
|
|
|
Re: orbit cvs repository [message #562946 is a reply to message #10602] |
Mon, 24 September 2007 07:38 |
|
Sorry, just read up on the Orbit structures. I took one thing for
granted, namely that the CVS was used to maintain the source of the
bundles. Apparently that's not the case at all. Which makes me wonder;
why use CVS in the first place? What benefits does it bring that the
download page doesn't?
A more natural way of doing it (to me that is) would be to explode the
source into CVS and maintain (and build from) that. Either that, or as I
mentioned earlier, simply import the project from a zipped archive (with
or without source).
- thomas
Thomas Hallgren wrote:
> Eike Stepper wrote:
>> Thomas Hallgren schrieb:
>>> Why do you need versions in project folders in order to check out
>>> different versionsinto your workspace? Why not just check out
>>> different tags into different projects?
>> I don't need them in the sense that I'd be unable to work with them
>> otherwise.
>> I just agree with Eugene in that it would be much simpler to have them
>> without branches.
>>
>> To repeat his arguments:
>> 1) Eclipse CVS client is not particularly well suited to work with
>> branches
>> 2) The projects we talk about in the context of Orbit are somewhat
>> immutable once they're released, i.e. they don't contain sources with
>> active development.
>> 3) If you need multiple versions of the same bundle at the same time
>> in your worksace you'd have to switch to the versioned project name
>> anyway.
>>
>> It would be much simpler to work with them if they are listed under
>> HEAD side by side.
>> Do you really disagree with that?
>
> To some extent yes, I do. What you really do is mirror source that is
> maintained in some other repository. If you did treat Orbit as a mirror
> and used tags (I'm not in favor of CVS branches either), you'd get the
> benefit of source history. IMO, imperative when you do impact analysis
> when incorporating a new version.
>
> Another, perhaps more biased reason is that some tools out there that
> are capable of transitive resolution and check-out, will not expect a
> cvs repository to be used this way. It defeats the reason for using a
> repository capable of versioning. Why use CVS in the first place? Why
> not just import a zipped bundle that contains source in that case?
>
> - thomas
|
|
|
Re: orbit cvs repository [message #562970 is a reply to message #10635] |
Mon, 24 September 2007 07:41 |
|
Thomas Hallgren schrieb:
> Sorry, just read up on the Orbit structures. I took one thing for
> granted, namely that the CVS was used to maintain the source of the
> bundles. Apparently that's not the case at all. Which makes me wonder;
> why use CVS in the first place? What benefits does it bring that the
> download page doesn't?
Good question. I guess it's due to requirements of the PDE build.
> A more natural way of doing it (to me that is) would be to explode the
> source into CVS and maintain (and build from) that. Either that, or as
> I mentioned earlier, simply import the project from a zipped archive
> (with or without source).
>
> - thomas
>
>
> Thomas Hallgren wrote:
>> Eike Stepper wrote:
>>> Thomas Hallgren schrieb:
>>>> Why do you need versions in project folders in order to check out
>>>> different versionsinto your workspace? Why not just check out
>>>> different tags into different projects?
>>> I don't need them in the sense that I'd be unable to work with them
>>> otherwise.
>>> I just agree with Eugene in that it would be much simpler to have
>>> them without branches.
>>>
>>> To repeat his arguments:
>>> 1) Eclipse CVS client is not particularly well suited to work with
>>> branches
>>> 2) The projects we talk about in the context of Orbit are somewhat
>>> immutable once they're released, i.e. they don't contain sources
>>> with active development.
>>> 3) If you need multiple versions of the same bundle at the same time
>>> in your worksace you'd have to switch to the versioned project name
>>> anyway.
>>>
>>> It would be much simpler to work with them if they are listed under
>>> HEAD side by side.
>>> Do you really disagree with that?
>>
>> To some extent yes, I do. What you really do is mirror source that is
>> maintained in some other repository. If you did treat Orbit as a
>> mirror and used tags (I'm not in favor of CVS branches either), you'd
>> get the benefit of source history. IMO, imperative when you do impact
>> analysis when incorporating a new version.
>>
>> Another, perhaps more biased reason is that some tools out there that
>> are capable of transitive resolution and check-out, will not expect a
>> cvs repository to be used this way. It defeats the reason for using a
>> repository capable of versioning. Why use CVS in the first place? Why
>> not just import a zipped bundle that contains source in that case?
>>
>> - thomas
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Sun Oct 06 11:17:08 GMT 2024
Powered by FUDForum. Page generated in 0.05607 seconds
|