You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ibatis.apache.org by Ted Husted <hu...@apache.org> on 2005/01/16 13:21:21 UTC
SVN Recap (was RE: ASF TODO [short] (was ASF TODO [long]))
Just to recap,
* I'd suggest that the SVN structure represent the subproject/release structure, where the subprojects are
** java/mapper
** java/dao
** java/docs
** java/jpetshore
** cs/mapper
** cs/dao
** cs/docs
** cs/npetshop
** cs/tutorial
** site
If we later change the release structure, we can change the SVN structure to match, since moving things around in Subversion is cheap.
* I'd suggest that we tag each subproject release before it is rolled. Ideally, the tag should identify exactly what goes into a given subproject release.
* Obviously, I don't care if we keep the tags in subdirectories or in a master directory at the top. My only concern is that it is easy to tag only the resources that pertain to a given release.
* I haven't done any SVN tagging myself, but someone who does said it was easier to create the tags if we we used a
/$subproject
./tag
./trunk
structure. Of course, it might be just as easy to keep them all at the root. I haven't had a chance to try yet.
* If someone wants to forward this post to a SVN guru, that would work for me :)
It will be a couple of days before the repos are rolled over, and we don't have to start shuffling things around right away, so time is not of the essence.
-Ted.
Re: SVN Recap (was RE: ASF TODO [short] (was ASF TODO [long]))
Posted by Clinton Begin <cl...@gmail.com>.
Arrgh! Unfortunately I've just realized that pretty much all of the
binary files are corrupt in the bzip2 archives from SourceForge. Also,
JPetStore 4 is missing from the jpetstore archives...how convenient.
I've emailed the SourceForge team. If they don't respond VERY
quickly, I'll simply delete all binary files and add them again
(unfortunate, but the source is more important). This will probably
set us back a day. So the archives likely won't be ready until
Wednesday. :-(
What can I say...I won't miss SourceForge!
Cheers,
Clinton
On Mon, 17 Jan 2005 13:39:28 -0700, Clinton Begin
<cl...@gmail.com> wrote:
> I'll excise the jars tonight. The complete repository archive will be
> available from my apache.org home directory by tomorrow morning. :-)
>
> Cheers,
> Clinton
>
> On Mon, 17 Jan 2005 15:36:25 -0500, Ted Husted <hu...@apache.org> wrote:
> >
> > I know there won't be any problem with converting the CVS repository. Infrastructure has done that dozens of times.
> >
> > Once it is up, they might also be able to merge in the ibatisnet1 hotcopy. If so, our revisions numbers would change, but we'd otherwise have all the history.
> >
> > If not, the worst case scenario is that we commit the latest ibatisnet to the new repository, and lose the history.
> >
> > Since the codebase is so young, that doesn't really bother me. (I don't know how Gilles and Roberto feel.) We still have the hotcopy, and we can still set it up for reference.
> >
> > And, a new ibatisnet commit also solves the problem of keeping the LGPL assemblies out of the ASF repository. :)
> >
> > Were you able to excise the JARs from CVS, Clinton?
> >
> > If the CVS tarball is ready to go, you can upload it to your ASF user directory, and we can take it from there.
> >
> > -Ted.
> >
> > On Mon, 17 Jan 2005 13:16:19 -0700, Clinton Begin wrote:
> > > I'm having no luck at all trying to convert the repository. It
> > > seems that despite the portable nature of Python, the Subversion
> > > team had to resort to using a number of native Linux utilities in
> > > the conversion script. Neither Cygwin nor UnixUtils has enough
> > > functionality to support it.
> > >
> > > I have a linux box that I could install Subversion on, but at this
> > > point I'd almost be happy enough just submitting the CVS tarball. :-
> > > )
> > >
> > > I'm not convinced that it will be any easier for the ops team to
> > > merge two SVN repositories vs. CVS + SVN. It looks like it will be
> > > a nightmare either way. In hindsight, a better approach would
> > > have been for us to keep both Java and .NET in CVS so that we could
> > > merge them and then convert them together as one.
> > >
> > > Cheers,
> > > Clinton
> > >
> > >
> > > On Mon, 17 Jan 2005 14:02:44 -0500, Ted Husted <hu...@apache.org>
> > > wrote:
> > >
> > >> The hotcopy of the ibatisnet1 SVN (r518) is available in my ASF
> > >> user directory
> > >>
> > >> * http://www.apache.org/~husted/ibatisnet1.tar.gz *
> > >> www.apache.org//users/husted/public_html/ibatisnet1.tar.gz
> > >>
> > >> I had thought we'd submit this and the CVS tarball to
> > >> infrastructure, to see what they could do. But, if we want to try
> > >> converting the ibatisdb CVS and merging it ourselves, then the
> > >> hotcopy is available for thT purpose as well.
> > >>
> > >> We might also consider asking Michael Ching at WUSH.NET if they
> > >> could convert the CVS tarball and merge it with our ibatisnet1
> > >> repository. Then, we could hand infrastructure a done deal.
> > >>
> > >> -Ted.
> > >>
> > >> To copy files to your user directory, you can use scp (or pscp if
> > >> you are using putty).
> > >>
> > >>> sc $filename $userid@www.apache.org://home/$userid/public_html
> > >>>
> > >> The wush.net hotcopy backup is available at
> > >> https://wush.net/members/download_backup.php (login with the
> > >> master account credentials).
> >
> >
>
Re: SVN Recap (was RE: ASF TODO [short] (was ASF TODO [long]))
Posted by Clinton Begin <cl...@gmail.com>.
I'll excise the jars tonight. The complete repository archive will be
available from my apache.org home directory by tomorrow morning. :-)
Cheers,
Clinton
On Mon, 17 Jan 2005 15:36:25 -0500, Ted Husted <hu...@apache.org> wrote:
>
> I know there won't be any problem with converting the CVS repository. Infrastructure has done that dozens of times.
>
> Once it is up, they might also be able to merge in the ibatisnet1 hotcopy. If so, our revisions numbers would change, but we'd otherwise have all the history.
>
> If not, the worst case scenario is that we commit the latest ibatisnet to the new repository, and lose the history.
>
> Since the codebase is so young, that doesn't really bother me. (I don't know how Gilles and Roberto feel.) We still have the hotcopy, and we can still set it up for reference.
>
> And, a new ibatisnet commit also solves the problem of keeping the LGPL assemblies out of the ASF repository. :)
>
> Were you able to excise the JARs from CVS, Clinton?
>
> If the CVS tarball is ready to go, you can upload it to your ASF user directory, and we can take it from there.
>
> -Ted.
>
> On Mon, 17 Jan 2005 13:16:19 -0700, Clinton Begin wrote:
> > I'm having no luck at all trying to convert the repository. It
> > seems that despite the portable nature of Python, the Subversion
> > team had to resort to using a number of native Linux utilities in
> > the conversion script. Neither Cygwin nor UnixUtils has enough
> > functionality to support it.
> >
> > I have a linux box that I could install Subversion on, but at this
> > point I'd almost be happy enough just submitting the CVS tarball. :-
> > )
> >
> > I'm not convinced that it will be any easier for the ops team to
> > merge two SVN repositories vs. CVS + SVN. It looks like it will be
> > a nightmare either way. In hindsight, a better approach would
> > have been for us to keep both Java and .NET in CVS so that we could
> > merge them and then convert them together as one.
> >
> > Cheers,
> > Clinton
> >
> >
> > On Mon, 17 Jan 2005 14:02:44 -0500, Ted Husted <hu...@apache.org>
> > wrote:
> >
> >> The hotcopy of the ibatisnet1 SVN (r518) is available in my ASF
> >> user directory
> >>
> >> * http://www.apache.org/~husted/ibatisnet1.tar.gz *
> >> www.apache.org//users/husted/public_html/ibatisnet1.tar.gz
> >>
> >> I had thought we'd submit this and the CVS tarball to
> >> infrastructure, to see what they could do. But, if we want to try
> >> converting the ibatisdb CVS and merging it ourselves, then the
> >> hotcopy is available for thT purpose as well.
> >>
> >> We might also consider asking Michael Ching at WUSH.NET if they
> >> could convert the CVS tarball and merge it with our ibatisnet1
> >> repository. Then, we could hand infrastructure a done deal.
> >>
> >> -Ted.
> >>
> >> To copy files to your user directory, you can use scp (or pscp if
> >> you are using putty).
> >>
> >>> sc $filename $userid@www.apache.org://home/$userid/public_html
> >>>
> >> The wush.net hotcopy backup is available at
> >> https://wush.net/members/download_backup.php (login with the
> >> master account credentials).
>
>
Re: SVN Recap (was RE: ASF TODO [short] (was ASF TODO [long]))
Posted by Ted Husted <hu...@apache.org>.
I know there won't be any problem with converting the CVS repository. Infrastructure has done that dozens of times.
Once it is up, they might also be able to merge in the ibatisnet1 hotcopy. If so, our revisions numbers would change, but we'd otherwise have all the history.
If not, the worst case scenario is that we commit the latest ibatisnet to the new repository, and lose the history.
Since the codebase is so young, that doesn't really bother me. (I don't know how Gilles and Roberto feel.) We still have the hotcopy, and we can still set it up for reference.
And, a new ibatisnet commit also solves the problem of keeping the LGPL assemblies out of the ASF repository. :)
Were you able to excise the JARs from CVS, Clinton?
If the CVS tarball is ready to go, you can upload it to your ASF user directory, and we can take it from there.
-Ted.
On Mon, 17 Jan 2005 13:16:19 -0700, Clinton Begin wrote:
>�I'm having no luck at all trying to convert the repository. �It
>�seems that despite the portable nature of Python, the Subversion
>�team had to resort to using a number of native Linux utilities in
>�the conversion script. �Neither Cygwin nor UnixUtils has enough
>�functionality to support it.
>
>�I have a linux box that I could install Subversion on, but at this
>�point I'd almost be happy enough just submitting the CVS tarball. :-
>�)
>
>�I'm not convinced that it will be any easier for the ops team to
>�merge two SVN repositories vs. CVS + SVN. �It looks like it will be
>� a nightmare either way. �In hindsight, a better approach would
>�have been for us to keep both Java and .NET in CVS so that we could
>�merge them and then convert them together as one.
>
>�Cheers,
>�Clinton
>
>
>�On Mon, 17 Jan 2005 14:02:44 -0500, Ted Husted <hu...@apache.org>
>�wrote:
>
>>�The hotcopy of the ibatisnet1 SVN (r518) is available in my ASF
>>�user directory
>>
>>�* http://www.apache.org/~husted/ibatisnet1.tar.gz *
>>�www.apache.org//users/husted/public_html/ibatisnet1.tar.gz
>>
>>�I had thought we'd submit this and the CVS tarball to
>>�infrastructure, to see what they could do. But, if we want to try
>>�converting the ibatisdb CVS and merging it ourselves, then the
>>�hotcopy is available for thT purpose as well.
>>
>>�We might also consider asking Michael Ching at WUSH.NET if they
>>�could convert the CVS tarball and merge it with our ibatisnet1
>>�repository. Then, we could hand infrastructure a done deal.
>>
>>�-Ted.
>>
>>�To copy files to your user directory, you can use scp (or pscp if
>>�you are using putty).
>>
>>>�sc $filename $userid@www.apache.org://home/$userid/public_html
>>>
>>�The wush.net hotcopy backup is available at
>>�https://wush.net/members/download_backup.php (login with the
>>�master account credentials).
Re: SVN Recap (was RE: ASF TODO [short] (was ASF TODO [long]))
Posted by Clinton Begin <cl...@gmail.com>.
I'm having no luck at all trying to convert the repository. It seems
that despite the portable nature of Python, the Subversion team had to
resort to using a number of native Linux utilities in the conversion
script. Neither Cygwin nor UnixUtils has enough functionality to
support it.
I have a linux box that I could install Subversion on, but at this
point I'd almost be happy enough just submitting the CVS tarball. :-)
I'm not convinced that it will be any easier for the ops team to merge
two SVN repositories vs. CVS + SVN. It looks like it will be a
nightmare either way. In hindsight, a better approach would have been
for us to keep both Java and .NET in CVS so that we could merge them
and then convert them together as one.
Cheers,
Clinton
On Mon, 17 Jan 2005 14:02:44 -0500, Ted Husted <hu...@apache.org> wrote:
> The hotcopy of the ibatisnet1 SVN (r518) is available in my ASF user directory
>
> * http://www.apache.org/~husted/ibatisnet1.tar.gz
> * www.apache.org//users/husted/public_html/ibatisnet1.tar.gz
>
> I had thought we'd submit this and the CVS tarball to infrastructure, to see what they could do. But, if we want to try converting the ibatisdb CVS and merging it ourselves, then the hotcopy is available for thT purpose as well.
>
> We might also consider asking Michael Ching at WUSH.NET if they could convert the CVS tarball and merge it with our ibatisnet1 repository. Then, we could hand infrastructure a done deal.
>
> -Ted.
>
> To copy files to your user directory, you can use scp (or pscp if you are using putty).
> > sc $filename $userid@www.apache.org://home/$userid/public_html
>
> The wush.net hotcopy backup is available at https://wush.net/members/download_backup.php (login with the master account credentials).
>
>
Re: SVN Recap (was RE: ASF TODO [short] (was ASF TODO [long]))
Posted by Ted Husted <hu...@apache.org>.
The hotcopy of the ibatisnet1 SVN (r518) is available in my ASF user directory
* http://www.apache.org/~husted/ibatisnet1.tar.gz
* www.apache.org//users/husted/public_html/ibatisnet1.tar.gz
I had thought we'd submit this and the CVS tarball to infrastructure, to see what they could do. But, if we want to try converting the ibatisdb CVS and merging it ourselves, then the hotcopy is available for thT purpose as well.
We might also consider asking Michael Ching at WUSH.NET if they could convert the CVS tarball and merge it with our ibatisnet1 repository. Then, we could hand infrastructure a done deal.
-Ted.
To copy files to your user directory, you can use scp (or pscp if you are using putty).
> sc $filename $userid@www.apache.org://home/$userid/public_html
The wush.net hotcopy backup is available at https://wush.net/members/download_backup.php (login with the master account credentials).
Re: SVN Recap (was RE: ASF TODO [short] (was ASF TODO [long]))
Posted by Clinton Begin <cl...@gmail.com>.
Yeah, easy repository migration, moving and merging is something the
SVN team could have done a little better.
I'm going to try to get the non-ASF stuff out before we migrate.
Cheers,
Clinton
On Sun, 16 Jan 2005 12:53:04 -0500, Ted Husted <hu...@apache.org> wrote:
> On Sun, 16 Jan 2005 10:32:20 -0700, Clinton Begin wrote:
> > Cool. I have the tarball from SourceForge. I was planning on
> > converting the repository from CVS to SVN and rearrange it as
> > described. Can our ops guys merge two SVN repositories? Or is
> > that a nightmare? Is it easier if I just leave it as CVS?
>
> I asked on the infrastructure list about merging and joining, and which way would be the best to go, but didn't get a response.
>
> I had thought we could just give them both tarballs and let whoever does it do the best they can. Once it was up, we could refactor it there.
>
> But, if we'd like to submit a more finished product to the ASF, we could ask WUSH.NET if they could convert the CVS and merge it our existing SVN repository. They did this for me with the Struts CVS, when we were deciding whether to go with SVN or not. The response time has always been good, generally over night.
>
> Or, if you want to convert and refactor it yourself, we could get the SVN dump of that, and see if WUSH.NET can merge it into ours.
>
> We could then get the dump of the combined WUSH.NET SVN and hand that to the infrastructure guys.
>
>
> > Also, with regard to the 3rd party (non-ASF) DLLs (Hibernate etc.),
> > are you physically deleting them from the repository (can you do
> > that with SVN)? I was going to delete the ,v file from cvs
> > entirely, so that the 3rd party jar files aren't even in history.
>
> It's not easy to remove any artifact from SVN. You can do it, but it's messy. But if we are transferring a dump, I believe we might be able to excise the folder in transit. (Beam me up, Scotty ... and can you remove the mole while you are at it?)
>
> The key point is whether the ASF is distributing a *GPL binary with it's own distribution. We haven't had an ASF distribution yet, so we are clear on that point.
>
> >
> > Cheers,
> > Clinton
>
> -Ted.
>
>
Re: SVN Recap (was RE: ASF TODO [short] (was ASF TODO [long]))
Posted by Ted Husted <hu...@apache.org>.
On Sun, 16 Jan 2005 10:32:20 -0700, Clinton Begin wrote:
>�Cool. �I have the tarball from SourceForge. �I was planning on
>�converting the repository from CVS to SVN and rearrange it as
>�described. �Can our ops guys merge two SVN repositories? �Or is
>�that a nightmare? �Is it easier if I just leave it as CVS?
I asked on the infrastructure list about merging and joining, and which way would be the best to go, but didn't get a response.
I had thought we could just give them both tarballs and let whoever does it do the best they can. Once it was up, we could refactor it there.
But, if we'd like to submit a more finished product to the ASF, we could ask WUSH.NET if they could convert the CVS and merge it our existing SVN repository. They did this for me with the Struts CVS, when we were deciding whether to go with SVN or not. The response time has always been good, generally over night.
Or, if you want to convert and refactor it yourself, we could get the SVN dump of that, and see if WUSH.NET can merge it into ours.
We could then get the dump of the combined WUSH.NET SVN and hand that to the infrastructure guys.
>�Also, with regard to the 3rd party (non-ASF) DLLs (Hibernate etc.),
>�are you physically deleting them from the repository (can you do
>�that with SVN)? �I was going to delete the ,v file from cvs
>�entirely, so that the 3rd party jar files aren't even in history.
It's not easy to remove any artifact from SVN. You can do it, but it's messy. But if we are transferring a dump, I believe we might be able to excise the folder in transit. (Beam me up, Scotty ... and can you remove the mole while you are at it?)
The key point is whether the ASF is distributing a *GPL binary with it's own distribution. We haven't had an ASF distribution yet, so we are clear on that point.
>
>�Cheers,
>�Clinton
-Ted.
Re: SVN Recap (was RE: ASF TODO [short] (was ASF TODO [long]))
Posted by Clinton Begin <cl...@gmail.com>.
Cool. I have the tarball from SourceForge. I was planning on
converting the repository from CVS to SVN and rearrange it as
described. Can our ops guys merge two SVN repositories? Or is that a
nightmare? Is it easier if I just leave it as CVS?
Also, with regard to the 3rd party (non-ASF) DLLs (Hibernate etc.),
are you physically deleting them from the repository (can you do that
with SVN)? I was going to delete the ,v file from cvs entirely, so
that the 3rd party jar files aren't even in history.
Cheers,
Clinton
On Sun, 16 Jan 2005 12:14:41 -0500, Ted Husted <hu...@apache.org> wrote:
> > Can we move forward with this?
>
> Sure, after the CVS and SVN repositories are brought over. :)
>
> By then, I'll be able to confirm that tagging the individual subprojects won't be a problem.
>
> I really should be tagging my own project releases, and I can start doing that on Monday. Like iBATIS (and Struts), we are running several different products with individual release cycles out of the same repository. We a release schedule for tomorrow to put the latest DataMapper binaries into production (yeah!), and I can update our repository to resemble this structure.
>
> -Ted.
>
> On Sun, 16 Jan 2005 09:31:03 -0700, Clinton Begin wrote:
> > So then, we have five +1s on the following directory structure:
> >
> > /branches (as required)
> > /tags
> > */java
> > **/releases
> > ***/2.1.0
> > */cs
> > **/releases
> > ***/1.5.0
> > /trunk
> > */site
> > */cs
> > **/mapper
> > **/dao
> > **/docs
> > **/npetshop
> > **/tutorial
> > */java
> > **/mapper
> > **/dao
> > **/docs
> > **/jpetstore
> >
> > With the understanding that we won't be moving DAO out just yet
> > (there's a bit of effort there).
> >
> > Can we move forward with this?
> >
> > Cheers,
> > Clinton
> >
> > On Sun, 16 Jan 2005 07:21:21 -0500, Ted Husted <hu...@apache.org>
> > wrote:
> >
> >> Just to recap,
> >>
> >> * I'd suggest that the SVN structure represent the
> >> subproject/release structure, where the subprojects are
> >>
> >> ** java/mapper
> >> ** java/dao
> >> ** java/docs
> >> ** java/jpetshore
> >>
> >> ** cs/mapper
> >> ** cs/dao
> >> ** cs/docs
> >> ** cs/npetshop
> >> ** cs/tutorial
> >>
> >> ** site
> >>
> >> If we later change the release structure, we can change the SVN
> >> structure to match, since moving things around in Subversion is
> >> cheap.
> >>
> >> * I'd suggest that we tag each subproject release before it is
> >> rolled. Ideally, the tag should identify exactly what goes into a
> >> given subproject release.
> >>
> >> * Obviously, I don't care if we keep the tags in subdirectories
> >> or in a master directory at the top. My only concern is that it
> >> is easy to tag only the resources that pertain to a given release.
> >>
> >> * I haven't done any SVN tagging myself, but someone who does
> >> said it was easier to create the tags if we we used a
> >>
> >> /$subproject
> >> ./tag
> >> ./trunk
> >>
> >> structure. Of course, it might be just as easy to keep them all
> >> at the root. I haven't had a chance to try yet.
> >>
> >> * If someone wants to forward this post to a SVN guru, that would
> >> work for me :)
> >>
> >> It will be a couple of days before the repos are rolled over, and
> >> we don't have to start shuffling things around right away, so
> >> time is not of the essence.
> >>
> >> -Ted.
>
>
Re: SVN Recap (was RE: ASF TODO [short] (was ASF TODO [long]))
Posted by Ted Husted <hu...@apache.org>.
>�Can we move forward with this?
Sure, after the CVS and SVN repositories are brought over. :)
By then, I'll be able to confirm that tagging the individual subprojects won't be a problem.
I really should be tagging my own project releases, and I can start doing that on Monday. Like iBATIS (and Struts), we are running several different products with individual release cycles out of the same repository. We a release schedule for tomorrow to put the latest DataMapper binaries into production (yeah!), and I can update our repository to resemble this structure.
-Ted.
On Sun, 16 Jan 2005 09:31:03 -0700, Clinton Begin wrote:
>�So then, we have five +1s on the following directory structure:
>
>�/branches (as required)
>�/tags
>�*/java
>�**/releases
>�***/2.1.0
>�*/cs
>�**/releases
>�***/1.5.0
>�/trunk
>�*/site
>�*/cs
>�**/mapper
>�**/dao
>�**/docs
>�**/npetshop
>�**/tutorial
>�*/java
>�**/mapper
>�**/dao
>�**/docs
>�**/jpetstore
>
>�With the understanding that we won't be moving DAO out just yet
>�(there's a bit of effort there).
>
>�Can we move forward with this?
>
>�Cheers,
>�Clinton
>
>�On Sun, 16 Jan 2005 07:21:21 -0500, Ted Husted <hu...@apache.org>
>�wrote:
>
>>�Just to recap,
>>
>>�* I'd suggest that the SVN structure represent the
>>�subproject/release structure, where the subprojects are
>>
>>�** java/mapper
>>�** java/dao
>>�** java/docs
>>�** java/jpetshore
>>
>>�** cs/mapper
>>�** cs/dao
>>�** cs/docs
>>�** cs/npetshop
>>�** cs/tutorial
>>
>>�** site
>>
>>�If we later change the release structure, we can change the SVN
>>�structure to match, since moving things around in Subversion is
>>�cheap.
>>
>>�* I'd suggest that we tag each subproject release before it is
>>�rolled. Ideally, the tag should identify exactly what goes into a
>>�given subproject release.
>>
>>�* Obviously, I don't care if we keep the tags in subdirectories
>>�or in a master directory at the top. My only concern is that it
>>�is easy to tag only the resources that pertain to a given release.
>>
>>�* I haven't done any SVN tagging myself, but someone who does
>>�said it was easier to create the tags if we we used a
>>
>>�/$subproject
>>�./tag
>>�./trunk
>>
>>�structure. �Of course, it might be just as easy to keep them all
>>�at the root. I haven't had a chance to try yet.
>>
>>�* If someone wants to forward this post to a SVN guru, that would
>>�work for me :)
>>
>>�It will be a couple of days before the repos are rolled over, and
>>�we don't have to start shuffling things around right away, so
>>�time is not of the essence.
>>
>>�-Ted.
Re: SVN Recap (was RE: ASF TODO [short] (was ASF TODO [long]))
Posted by Clinton Begin <cl...@gmail.com>.
So then, we have five +1s on the following directory structure:
/branches (as required)
/tags
*/java
**/releases
***/2.1.0
*/cs
**/releases
***/1.5.0
/trunk
*/site
*/cs
**/mapper
**/dao
**/docs
**/npetshop
**/tutorial
*/java
**/mapper
**/dao
**/docs
**/jpetstore
With the understanding that we won't be moving DAO out just yet
(there's a bit of effort there).
Can we move forward with this?
Cheers,
Clinton
On Sun, 16 Jan 2005 07:21:21 -0500, Ted Husted <hu...@apache.org> wrote:
> Just to recap,
>
> * I'd suggest that the SVN structure represent the subproject/release structure, where the subprojects are
>
> ** java/mapper
> ** java/dao
> ** java/docs
> ** java/jpetshore
>
> ** cs/mapper
> ** cs/dao
> ** cs/docs
> ** cs/npetshop
> ** cs/tutorial
>
> ** site
>
> If we later change the release structure, we can change the SVN structure to match, since moving things around in Subversion is cheap.
>
> * I'd suggest that we tag each subproject release before it is rolled. Ideally, the tag should identify exactly what goes into a given subproject release.
>
> * Obviously, I don't care if we keep the tags in subdirectories or in a master directory at the top. My only concern is that it is easy to tag only the resources that pertain to a given release.
>
> * I haven't done any SVN tagging myself, but someone who does said it was easier to create the tags if we we used a
>
> /$subproject
> ./tag
> ./trunk
>
> structure. Of course, it might be just as easy to keep them all at the root. I haven't had a chance to try yet.
>
> * If someone wants to forward this post to a SVN guru, that would work for me :)
>
> It will be a couple of days before the repos are rolled over, and we don't have to start shuffling things around right away, so time is not of the essence.
>
> -Ted.
>
>
RE: SVN Recap (was RE: ASF TODO [short] (was ASF TODO [long]))
Posted by Gilles Bayon <gi...@laposte.net>.
> -----Message d'origine-----
> De : Ted Husted
> Envoyé : dimanche 16 janvier 2005 13:21
> À : ibatis-dev@incubator.apache.org
> Objet : SVN Recap (was RE: ASF TODO [short] (was ASF TODO [long]))
>
> Just to recap,
>
> * I'd suggest that the SVN structure represent the subproject/release
> structure, where the subprojects are
>
> ** java/mapper
> ** java/dao
> ** java/docs
> ** java/jpetshore
>
> ** cs/mapper
> ** cs/dao
> ** cs/docs
> ** cs/npetshop
> ** cs/tutorial
>
> ** site
>
> If we later change the release structure, we can change the SVN
> structure to match, since moving things around in Subversion is cheap.
>
> * I'd suggest that we tag each subproject release before it is rolled.
> Ideally, the tag should identify exactly what goes into a given subproject
> release.
>
> * Obviously, I don't care if we keep the tags in subdirectories or in a
> master directory at the top. My only concern is that it is easy to tag
> only the resources that pertain to a given release.
+1
> * I haven't done any SVN tagging myself, but someone who does said it was
> easier to create the tags if we we used a
>
> /$subproject
> ./tag
> ./trunk
>
> structure. Of course, it might be just as easy to keep them all at the
> root. I haven't had a chance to try yet.
I have done a tag for the last .NET release and
it's very easy you can put your tag in any directory (root ou sub).
> * If someone wants to forward this post to a SVN guru, that would work for
> me :)
>
> It will be a couple of days before the repos are rolled over, and we don't
> have to start shuffling things around right away, so time is not of the
> essence.
>
> -Ted.
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.12 - Release Date: 14/01/2005
RE: SVN Recap (was RE: ASF TODO [short] (was ASF TODO [long]))
Posted by Gilles Bayon <gi...@laposte.net>.
> -----Message d'origine-----
> De : Ted Husted
> Envoyé : dimanche 16 janvier 2005 13:35
> À : ibatis-dev@incubator.apache.org
> Objet : Re: SVN Recap (was RE: ASF TODO [short] (was ASF TODO [long]))
>
> On Sun, 16 Jan 2005 07:21:21 -0500, Ted Husted wrote:
> > * I'd suggest that we tag each subproject release before it is
> > rolled. Ideally, the tag should identify exactly what goes into a
> > given subproject release.
>
> Which implies that the head for each subproject is not required to build
> against the head of every other subproject (on the same platform).
>
> For example, right now, C# DataMapper 1.5.0 depends on DataAccess 1.1.0.
False, it's the C# DataAccess 1.5.0 which use C# DataMapper 1.1
> Theoretically, we might decide to make some changes for DataMapper 1.6.x,
> which might not be compatible with DataAccess 1.1.x. We might want to get
> a release of DataMapper 1.6.0 out first, and then bring out an updated
> DataAccess release. After all, not everyone uses DataAccess.
>
> Later, when we get to it, we could then bring out an an updated NPetShop
> release that uses the new "best available" DataMapper and DataAccess
> releases.
>
> In the meantime, the old NPetShop will work just fine with the old
> DataAccess package, which works just fine with the old DataMapper package.
>
> I'm a little sensitive to this issue because we had such great problems
> during the Struts 1.1 "death march". We had to get all the "subprojects"
> just right before releasing anything. I just want to be sure that we have
> a project structure that would allow us to do one thing at a time.
>
> Of course, Team iBATIS has been doing this all along. For example, the
> documentation is not re-released just because a new SQL Mapper ships.
> Ditto for JPetstore. I just want to make sure we stay that course.
>
> -Ted.
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.6.12 - Release Date: 14/01/2005
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.12 - Release Date: 14/01/2005
Re: SVN Recap (was RE: ASF TODO [short] (was ASF TODO [long]))
Posted by Ted Husted <hu...@apache.org>.
On Sun, 16 Jan 2005 07:21:21 -0500, Ted Husted wrote:
> * I'd suggest that we tag each subproject release before it is
> rolled. Ideally, the tag should identify exactly what goes into a
> given subproject release.
Which implies that the head for each subproject is not required to build against the head of every other subproject (on the same platform).
For example, right now, C# DataMapper 1.5.0 depends on DataAccess 1.1.0.
Theoretically, we might decide to make some changes for DataMapper 1.6.x, which might not be compatible with DataAccess 1.1.x. We might want to get a release of DataMapper 1.6.0 out first, and then bring out an updated DataAccess release. After all, not everyone uses DataAccess.
Later, when we get to it, we could then bring out an an updated NPetShop release that uses the new "best available" DataMapper and DataAccess releases.
In the meantime, the old NPetShop will work just fine with the old DataAccess package, which works just fine with the old DataMapper package.
I'm a little sensitive to this issue because we had such great problems during the Struts 1.1 "death march". We had to get all the "subprojects" just right before releasing anything. I just want to be sure that we have a project structure that would allow us to do one thing at a time.
Of course, Team iBATIS has been doing this all along. For example, the documentation is not re-released just because a new SQL Mapper ships. Ditto for JPetstore. I just want to make sure we stay that course.
-Ted.