You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Martin Cooper <ma...@apache.org> on 2004/09/26 20:48:46 UTC
Important decisions prior to Subversion conversion
There are a couple of things that I think we need to decide on before we
make the final conversion of our repository to Subversion. They fall under
the headings of "what" and "where".
WHAT TO CONVERT
A default "whole enchilada" conversion of the Struts CVS repo will consume
about 1GB of disk space with almost 200,000 files and over 65,000 folders.
Much of this is, IMHO, stuff that we are extremely unlikely to ever want.
For example, this includes the following tags:
first
firstRelease
start
STRUTS_0_5
STRUTS_1_0
STRUTS_1_0_1
STRUTS_1_0_2
STRUTS_1_0_B1
STRUTS_1_0_B2
STRUTS_1_0_B3
STRUTS_1_1
STRUTS_1_1_B1
STRUTS_1_1_B2
STRUTS_1_1_B3
STRUTS_1_1_RC1
STRUTS_1_1_RC2
STRUTS_1_2_0
STRUTS_1_2_1
STRUTS_1_2_2
STRUTS_1_2_3
STRUTS_1_2_4
upload_1
and the following branches:
Cedric
jakarta
jakarta-struts
jakarta-struts-chain
STRUTS_1_0_BRANCH
STRUTS_1_1_BRANCH
STRUTS_PRE_1_0
upload
This is a lot of stuff! Also, I'm hoping someone else (Craig?) knows what
all of this is, because I don't know what any of the non-upper-case tags
or branches are (other than 'start' and 'upload*').
My proposal is this:
1) Drop all Beta and Release Candidate tags. I just don't see why we would
ever need to access those from Subversion.
2) Drop 1.2.x tags prior to 1.2.4, for the same reason as above. I don't
feel as strongly about this as about (1), so if others feel that we should
keep these due to their recent nature, I wouldn't object.
3) Drop the 'upload_1' tag and the 'upload' branch, which are related to
the original now-obsolete multipart request handling.
4) Drop the 'Cedric' and 'jakarta-struts' branches, unless Cedric feels we
should keep them. These are related to when Tiles was under 'contrib'.
We could also drop other tags and branches, but I myself wouldn't feel
comfortable doing so unless we know what they are first. ;-}
One point to note here is that the CVS repository will still exist after
the Subversion conversion. It just will no longer be writeable.
WHERE TO CONVERT
This question comes up because we know we want to restructure the repo
into multiple independently releasable units. By default, the conversion
will give us one 'trunk' directory with the same contents as a checkout
from CVS does today.
A message from Henri Yandell on the Jakarta General list got me looking at
what other projects have done in Subversion. You can see that here:
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN
There seem to be a number of different approaches. For the most part, I
believe we could go with the default and change things around later if we
need to. The one exception looks to be if we want to go with what the
'incubator' and 'portals' projects (amongst others) have done.
In these projects, there are multiple directories under the root - and in
some cases, multiple levels - each of which eventually has its own set of
trunk, tags, branches directories. I don't know enough about Subversion to
know all of the advantages and disadvantages of going this route. However,
it strikes me that it makes the higher level directories (sub-projects)
somewhat more self-contained, and allows them to retain their own sets of
branches and tags, independent of the others. On the other hand, it would
make it harder to tag the entire project, if we ever wanted to do that.
If we want to go with the 'incubator' style, then I think we'd need to
convert our CVS repo into a directory one level down from the top of the
new SVN repo, which is why I brought all this up.
On both of these topics, input from people with more Subversion experience
than I have would be much appreciated. Of course, input from everyone is
welcome too! This is an important decision for us.
--
Martin Cooper
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Important decisions prior to Subversion conversion
Posted by Cedric Dumoulin <ce...@lifl.fr>.
Martin Cooper wrote:
>
> 4) Drop the 'Cedric' and 'jakarta-struts' branches, unless Cedric
> feels we should keep them. These are related to when Tiles was under
> 'contrib'.
You can drop it.
Cedric
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Important decisions prior to Subversion conversion
Posted by Don Brown <mr...@twdata.org>.
Martin Cooper wrote:
> <snip />
>
>> Why do simple tags (as opposed to branch tags) cost anything to keep?
>> In CVS (at least), they don't require any duplicated storage. Does
>> the conversion to SVN turn them (effectively) into branches?
>
>
> My understanding is that tags and branches are the same thing in SVN,
> and it's only our conventions that make them different. (That is, tags
> are, by convention, read-only, while branches are writeable.) So a tag
> is a copy, just as a branch is a copy.
>
> The cvs2svn manual does state that one of the pros to what they refer
> to as the "pick and choose" approach is saving some space, but it
> doesn't say how much. I expect that would depend on which persistence
> option was chosen for the repo when it was set up. (I think the
> version infra@ has installed at the moment only has one option, which
> is some kind of database.)
Correct, a tag is a branch is a copy. The copy command is cheap since a
link is made to the original file in the database, rather than the
content copied itself. Subversion uses Berkley DB as its persistence
store. I think space should only be a consideration of infrastructure
thinkis it should be, and there isn't any mention of it in the
conversion instructions.
>
>>> 2) Drop 1.2.x tags prior to 1.2.4, for the same reason as above. I
>>> don't
>>> feel as strongly about this as about (1), so if others feel that we
>>> should
>>> keep these due to their recent nature, I wouldn't object.
>>
>>
>> What happens to the SVN equivalent to "cvs log" when you drop stuff
>> like this? If you lose the history of *all* changes to the files,
>> then it would probably be better just to snapshot the current trunk
>> (which implicitly eliminates all the old branches and tags), and just
>> keep the old CVS repo around (in read only mode).
>
>
> That's a good question, and I don't know the answer. My guess would be
> that you wouldn't lose anything, because each branch and tag is a
> copy, but everything is still in trunk. But that is a guess, and we
> should check to be sure.
Since branches and tags are copies, there isn't really anything gained
by excluding them from the conversion. Simply remove them later if needed.
>
>> Partial history transfer would be much worse, IMHO, than no history
>> transfer.
>
>
> Agreed.
>
>>> 3) Drop the 'upload_1' tag and the 'upload' branch, which are
>>> related to
>>> the original now-obsolete multipart request handling.
>>
>>
>> Don't have any problem with this, unless it removes data from the file
>> histories (see above).
>>
>>> 4) Drop the 'Cedric' and 'jakarta-struts' branches, unless Cedric
>>> feels we
>>> should keep them. These are related to when Tiles was under 'contrib'.
>>
>>
>> Same.
>>
>>>
>>> We could also drop other tags and branches, but I myself wouldn't feel
>>> comfortable doing so unless we know what they are first. ;-}
>>>
>>> One point to note here is that the CVS repository will still exist
>>> after
>>> the Subversion conversion. It just will no longer be writeable.
>>>
>>> WHERE TO CONVERT
>>>
>>> This question comes up because we know we want to restructure the repo
>>> into multiple independently releasable units. By default, the
>>> conversion
>>> will give us one 'trunk' directory with the same contents as a checkout
>>> from CVS does today.
>>>
>>> A message from Henri Yandell on the Jakarta General list got me
>>> looking at
>>> what other projects have done in Subversion. You can see that here:
>>>
>>> http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN
>>>
>>> There seem to be a number of different approaches. For the most part, I
>>> believe we could go with the default and change things around later
>>> if we
>>> need to. The one exception looks to be if we want to go with what the
>>> 'incubator' and 'portals' projects (amongst others) have done.
>>>
>>> In these projects, there are multiple directories under the root -
>>> and in
>>> some cases, multiple levels - each of which eventually has its own
>>> set of
>>> trunk, tags, branches directories. I don't know enough about
>>> Subversion to
>>> know all of the advantages and disadvantages of going this route.
>>> However,
>>> it strikes me that it makes the higher level directories (sub-projects)
>>> somewhat more self-contained, and allows them to retain their own
>>> sets of
>>> branches and tags, independent of the others. On the other hand, it
>>> would
>>> make it harder to tag the entire project, if we ever wanted to do that.
>>>
>>> If we want to go with the 'incubator' style, then I think we'd need to
>>> convert our CVS repo into a directory one level down from the top of
>>> the
>>> new SVN repo, which is why I brought all this up.
>>>
>>> On both of these topics, input from people with more Subversion
>>> experience
>>> than I have would be much appreciated. Of course, input from
>>> everyone is
>>> welcome too! This is an important decision for us.
>>>
>>> --
>>> Martin Cooper
>>
>>
>> When we were playing around with the test SVN repository, it took me
>> less than an hour to refactor just the stuff that would go into a
>> struts core distribution -- and it was possible to do this without
>> losing any file history. You can even refactor with "copy" instead of
>> "move" if you want to maintain the old structure as well (although I
>> wouldn't recommend that).
>>
>> Therefore, I'm +1 on migrating to SVN before refactoring, and -0 on
>> waiting any longer to migrate while we try to predict what the revised
>> organization should be ahead of time.
>
>
> Just to be clear, I wasn't suggesting we wait until we've decided the
> future repo organisation. I was just pointing out that we may not want
> to commit ourselves to having everything under one 'trunk', which is
> what I believe we would be doing by default. Refactoring *within* the
> trunk is easy enough, but what if we want to push 'trunk' down under
> another level of directory, so that we could have more than one, *if*
> we decide to do that at a later date? Is that something that we can do
> after the repo is created? I don't know the answer myself, but I would
> suspect not, which is why I brought it up.
>
Yes, you can refactor to your hearts content once the conversion takes
place. You can move, copy, or delete anything you want, including the
/trunk /branches /tags directories. By default, we get:
/struts/trunk
/struts/branches
/struts/tags
But later we want:
/struts/core/trunk
/struts/core/branches
/struts/core/tags
/struts/jsf/trunk
....
That isn't a problem.
Thus, I propose we ask infrastructure to make the switch at their
earliest convenience on Wednesday.
Don
> --
> Martin Cooper
>
>
>>
>> Craig
>>
>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Important decisions prior to Subversion conversion
Posted by Martin Cooper <ma...@apache.org>.
On Sun, 26 Sep 2004, Craig McClanahan wrote:
> See intermixed.
>
>
> On Sun, 26 Sep 2004 11:48:46 -0700 (PDT), Martin Cooper
> <ma...@apache.org> wrote:
>> There are a couple of things that I think we need to decide on before we
>> make the final conversion of our repository to Subversion. They fall under
>> the headings of "what" and "where".
>>
>> WHAT TO CONVERT
>>
>> A default "whole enchilada" conversion of the Struts CVS repo will consume
>> about 1GB of disk space with almost 200,000 files and over 65,000 folders.
>> Much of this is, IMHO, stuff that we are extremely unlikely to ever want.
>> For example, this includes the following tags:
>>
>> first
>> firstRelease
>> start
>> STRUTS_0_5
>> STRUTS_1_0
>> STRUTS_1_0_1
>> STRUTS_1_0_2
>> STRUTS_1_0_B1
>> STRUTS_1_0_B2
>> STRUTS_1_0_B3
>> STRUTS_1_1
>> STRUTS_1_1_B1
>> STRUTS_1_1_B2
>> STRUTS_1_1_B3
>> STRUTS_1_1_RC1
>> STRUTS_1_1_RC2
>> STRUTS_1_2_0
>> STRUTS_1_2_1
>> STRUTS_1_2_2
>> STRUTS_1_2_3
>> STRUTS_1_2_4
>> upload_1
>>
>> and the following branches:
>>
>> Cedric
>> jakarta
>> jakarta-struts
>> jakarta-struts-chain
>> STRUTS_1_0_BRANCH
>> STRUTS_1_1_BRANCH
>> STRUTS_PRE_1_0
>> upload
>>
>> This is a lot of stuff! Also, I'm hoping someone else (Craig?) knows what
>> all of this is, because I don't know what any of the non-upper-case tags
>> or branches are (other than 'start' and 'upload*').
>>
>
> I don't know what the "first" and "firstRelease" tags are, or remember
> why the non-upper-case branches were created.
>
>> My proposal is this:
>>
>> 1) Drop all Beta and Release Candidate tags. I just don't see why we would
>> ever need to access those from Subversion.
>
> Why do simple tags (as opposed to branch tags) cost anything to keep?
> In CVS (at least), they don't require any duplicated storage. Does
> the conversion to SVN turn them (effectively) into branches?
My understanding is that tags and branches are the same thing in SVN, and
it's only our conventions that make them different. (That is, tags are, by
convention, read-only, while branches are writeable.) So a tag is a copy,
just as a branch is a copy.
The cvs2svn manual does state that one of the pros to what they refer to
as the "pick and choose" approach is saving some space, but it doesn't say
how much. I expect that would depend on which persistence option was
chosen for the repo when it was set up. (I think the version infra@ has
installed at the moment only has one option, which is some kind of
database.)
>> 2) Drop 1.2.x tags prior to 1.2.4, for the same reason as above. I don't
>> feel as strongly about this as about (1), so if others feel that we should
>> keep these due to their recent nature, I wouldn't object.
>
> What happens to the SVN equivalent to "cvs log" when you drop stuff
> like this? If you lose the history of *all* changes to the files,
> then it would probably be better just to snapshot the current trunk
> (which implicitly eliminates all the old branches and tags), and just
> keep the old CVS repo around (in read only mode).
That's a good question, and I don't know the answer. My guess would be
that you wouldn't lose anything, because each branch and tag is a copy,
but everything is still in trunk. But that is a guess, and we should check
to be sure.
> Partial history transfer would be much worse, IMHO, than no history transfer.
Agreed.
>> 3) Drop the 'upload_1' tag and the 'upload' branch, which are related to
>> the original now-obsolete multipart request handling.
>
> Don't have any problem with this, unless it removes data from the file
> histories (see above).
>
>> 4) Drop the 'Cedric' and 'jakarta-struts' branches, unless Cedric feels we
>> should keep them. These are related to when Tiles was under 'contrib'.
>
> Same.
>
>>
>> We could also drop other tags and branches, but I myself wouldn't feel
>> comfortable doing so unless we know what they are first. ;-}
>>
>> One point to note here is that the CVS repository will still exist after
>> the Subversion conversion. It just will no longer be writeable.
>>
>> WHERE TO CONVERT
>>
>> This question comes up because we know we want to restructure the repo
>> into multiple independently releasable units. By default, the conversion
>> will give us one 'trunk' directory with the same contents as a checkout
>> from CVS does today.
>>
>> A message from Henri Yandell on the Jakarta General list got me looking at
>> what other projects have done in Subversion. You can see that here:
>>
>> http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN
>>
>> There seem to be a number of different approaches. For the most part, I
>> believe we could go with the default and change things around later if we
>> need to. The one exception looks to be if we want to go with what the
>> 'incubator' and 'portals' projects (amongst others) have done.
>>
>> In these projects, there are multiple directories under the root - and in
>> some cases, multiple levels - each of which eventually has its own set of
>> trunk, tags, branches directories. I don't know enough about Subversion to
>> know all of the advantages and disadvantages of going this route. However,
>> it strikes me that it makes the higher level directories (sub-projects)
>> somewhat more self-contained, and allows them to retain their own sets of
>> branches and tags, independent of the others. On the other hand, it would
>> make it harder to tag the entire project, if we ever wanted to do that.
>>
>> If we want to go with the 'incubator' style, then I think we'd need to
>> convert our CVS repo into a directory one level down from the top of the
>> new SVN repo, which is why I brought all this up.
>>
>> On both of these topics, input from people with more Subversion experience
>> than I have would be much appreciated. Of course, input from everyone is
>> welcome too! This is an important decision for us.
>>
>> --
>> Martin Cooper
>
> When we were playing around with the test SVN repository, it took me
> less than an hour to refactor just the stuff that would go into a
> struts core distribution -- and it was possible to do this without
> losing any file history. You can even refactor with "copy" instead of
> "move" if you want to maintain the old structure as well (although I
> wouldn't recommend that).
>
> Therefore, I'm +1 on migrating to SVN before refactoring, and -0 on
> waiting any longer to migrate while we try to predict what the revised
> organization should be ahead of time.
Just to be clear, I wasn't suggesting we wait until we've decided the
future repo organisation. I was just pointing out that we may not want to
commit ourselves to having everything under one 'trunk', which is what I
believe we would be doing by default. Refactoring *within* the trunk is
easy enough, but what if we want to push 'trunk' down under another level
of directory, so that we could have more than one, *if* we decide to do
that at a later date? Is that something that we can do after the repo is
created? I don't know the answer myself, but I would suspect not, which is
why I brought it up.
--
Martin Cooper
>
> Craig
>
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Important decisions prior to Subversion conversion
Posted by Craig McClanahan <cr...@gmail.com>.
See intermixed.
On Sun, 26 Sep 2004 11:48:46 -0700 (PDT), Martin Cooper
<ma...@apache.org> wrote:
> There are a couple of things that I think we need to decide on before we
> make the final conversion of our repository to Subversion. They fall under
> the headings of "what" and "where".
>
> WHAT TO CONVERT
>
> A default "whole enchilada" conversion of the Struts CVS repo will consume
> about 1GB of disk space with almost 200,000 files and over 65,000 folders.
> Much of this is, IMHO, stuff that we are extremely unlikely to ever want.
> For example, this includes the following tags:
>
> first
> firstRelease
> start
> STRUTS_0_5
> STRUTS_1_0
> STRUTS_1_0_1
> STRUTS_1_0_2
> STRUTS_1_0_B1
> STRUTS_1_0_B2
> STRUTS_1_0_B3
> STRUTS_1_1
> STRUTS_1_1_B1
> STRUTS_1_1_B2
> STRUTS_1_1_B3
> STRUTS_1_1_RC1
> STRUTS_1_1_RC2
> STRUTS_1_2_0
> STRUTS_1_2_1
> STRUTS_1_2_2
> STRUTS_1_2_3
> STRUTS_1_2_4
> upload_1
>
> and the following branches:
>
> Cedric
> jakarta
> jakarta-struts
> jakarta-struts-chain
> STRUTS_1_0_BRANCH
> STRUTS_1_1_BRANCH
> STRUTS_PRE_1_0
> upload
>
> This is a lot of stuff! Also, I'm hoping someone else (Craig?) knows what
> all of this is, because I don't know what any of the non-upper-case tags
> or branches are (other than 'start' and 'upload*').
>
I don't know what the "first" and "firstRelease" tags are, or remember
why the non-upper-case branches were created.
> My proposal is this:
>
> 1) Drop all Beta and Release Candidate tags. I just don't see why we would
> ever need to access those from Subversion.
Why do simple tags (as opposed to branch tags) cost anything to keep?
In CVS (at least), they don't require any duplicated storage. Does
the conversion to SVN turn them (effectively) into branches?
> 2) Drop 1.2.x tags prior to 1.2.4, for the same reason as above. I don't
> feel as strongly about this as about (1), so if others feel that we should
> keep these due to their recent nature, I wouldn't object.
What happens to the SVN equivalent to "cvs log" when you drop stuff
like this? If you lose the history of *all* changes to the files,
then it would probably be better just to snapshot the current trunk
(which implicitly eliminates all the old branches and tags), and just
keep the old CVS repo around (in read only mode).
Partial history transfer would be much worse, IMHO, than no history transfer.
> 3) Drop the 'upload_1' tag and the 'upload' branch, which are related to
> the original now-obsolete multipart request handling.
Don't have any problem with this, unless it removes data from the file
histories (see above).
> 4) Drop the 'Cedric' and 'jakarta-struts' branches, unless Cedric feels we
> should keep them. These are related to when Tiles was under 'contrib'.
Same.
>
> We could also drop other tags and branches, but I myself wouldn't feel
> comfortable doing so unless we know what they are first. ;-}
>
> One point to note here is that the CVS repository will still exist after
> the Subversion conversion. It just will no longer be writeable.
>
> WHERE TO CONVERT
>
> This question comes up because we know we want to restructure the repo
> into multiple independently releasable units. By default, the conversion
> will give us one 'trunk' directory with the same contents as a checkout
> from CVS does today.
>
> A message from Henri Yandell on the Jakarta General list got me looking at
> what other projects have done in Subversion. You can see that here:
>
> http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN
>
> There seem to be a number of different approaches. For the most part, I
> believe we could go with the default and change things around later if we
> need to. The one exception looks to be if we want to go with what the
> 'incubator' and 'portals' projects (amongst others) have done.
>
> In these projects, there are multiple directories under the root - and in
> some cases, multiple levels - each of which eventually has its own set of
> trunk, tags, branches directories. I don't know enough about Subversion to
> know all of the advantages and disadvantages of going this route. However,
> it strikes me that it makes the higher level directories (sub-projects)
> somewhat more self-contained, and allows them to retain their own sets of
> branches and tags, independent of the others. On the other hand, it would
> make it harder to tag the entire project, if we ever wanted to do that.
>
> If we want to go with the 'incubator' style, then I think we'd need to
> convert our CVS repo into a directory one level down from the top of the
> new SVN repo, which is why I brought all this up.
>
> On both of these topics, input from people with more Subversion experience
> than I have would be much appreciated. Of course, input from everyone is
> welcome too! This is an important decision for us.
>
> --
> Martin Cooper
When we were playing around with the test SVN repository, it took me
less than an hour to refactor just the stuff that would go into a
struts core distribution -- and it was possible to do this without
losing any file history. You can even refactor with "copy" instead of
"move" if you want to maintain the old structure as well (although I
wouldn't recommend that).
Therefore, I'm +1 on migrating to SVN before refactoring, and -0 on
waiting any longer to migrate while we try to predict what the revised
organization should be ahead of time.
Craig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org