[OT] CVS question

ruby-talk
1

Sorry to post this question here, but it IS marginally Ruby-related...

[ahem] anyway, here goes.

I just finished rewriting Copland, almost from the ground up. I'll be announcing the new version soon(ish), but I need to get it into CVS. Now, there's already an existing implementation of Copland in CVS, but I'd (obviously) like to replace it with the new version.

What is the best way to go about this? Right now, I'm leaning towards doing a "cvs delete" on the existing implementation, and then checking in the new implementation on top of it. Thus, the existing version history is maintained, etc. Is there a better way to do this?

Another option is to create a new module in CVS, calling it "copland2" or something. However, Copland is really still in a "pre-1.0" state, and I don't want to give the wrong impression by artificially bumping it to a post-1.0 version number. The rewrite was necessary to add some new functionality (like fail-fast and better schema validation), but on the surface there really isn't anything new...

Anyway, suggestions from anyone older-and-wiser would be appreciated. Thanks!

···

--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis

"I use octal until I get to 8, and then I switch to decimal."

2

I would tag the existing version -- and perhaps even branch it. All
of my programs and libraries are tagged and branched on major
releases (e.g., X.0.0 or X.Y.0). A notable exception is Ruwiki
0.8.0; it will not be branched until 0.8.1 becuase of some known
large changes that I want to carry forward to 0.9 even with planned
bugfixes.

At any rate, tag and branch copland as it stands. Then, do a CVS
delete on those files that no longer exist in copland. After adding
the new files, update, then tag and branch again.

-austin

···

On Fri, 27 Aug 2004 13:33:04 +0900, Jamis Buck <jgb3@email.byu.edu> wrote:

Sorry to post this question here, but it IS marginally
Ruby-related...

[ahem] anyway, here goes.

I just finished rewriting Copland, almost from the ground up. I'll
be announcing the new version soon(ish), but I need to get it into
CVS. Now, there's already an existing implementation of Copland in
CVS, but I'd (obviously) like to replace it with the new version.

What is the best way to go about this? Right now, I'm leaning
towards doing a "cvs delete" on the existing implementation, and
then checking in the new implementation on top of it. Thus, the
existing version history is maintained, etc. Is there a better way
to do this?

Another option is to create a new module in CVS, calling it
"copland2" or something. However, Copland is really still in a
"pre-1.0" state, and I don't want to give the wrong impression by
artificially bumping it to a post-1.0 version number. The rewrite
was necessary to add some new functionality (like fail-fast and
better schema validation), but on the surface there really isn't
anything new...

Anyway, suggestions from anyone older-and-wiser would be
appreciated. Thanks!

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

3

Don't try and do too much through CVS; it's a massive pain to reorganize a
project through CVS. Instead, edit the CVS repository directly.

If Copland was working on major version 1 before, just go into the repository,
create a new directory named v1 in the copland dir, and mv everything into
it. It's really that simple. Then you should 'cvs co copland/v1' where you
develop and work on that copy.

Then in your new version, get rid of all your CVS directories and 'cvs import
copland/v2 yourname start' and then 'cvs co copland/v2' where you want to
work on it.

Some of those CVS commands are pseudo'd, but you get the idea. Be sure to
match the ownership and permissions so you can access everything from your
user account.

Sean O'Dell

···

On Thursday 26 August 2004 21:33, Jamis Buck wrote:

I just finished rewriting Copland, almost from the ground up. I'll be
announcing the new version soon(ish), but I need to get it into CVS.
Now, there's already an existing implementation of Copland in CVS, but
I'd (obviously) like to replace it with the new version.

What is the best way to go about this? Right now, I'm leaning towards
doing a "cvs delete" on the existing implementation, and then checking
in the new implementation on top of it. Thus, the existing version
history is maintained, etc. Is there a better way to do this?

4

Austin Ziegler wrote:

I would tag the existing version -- and perhaps even branch it. All
of my programs and libraries are tagged and branched on major
releases (e.g., X.0.0 or X.Y.0). A notable exception is Ruwiki
0.8.0; it will not be branched until 0.8.1 becuase of some known
large changes that I want to carry forward to 0.9 even with planned
bugfixes.

At any rate, tag and branch copland as it stands. Then, do a CVS
delete on those files that no longer exist in copland. After adding
the new files, update, then tag and branch again.

-austin

Thanks for the advice, Austin. I'm familiar with tagging, but I guess I better just bite the bullet and read up on branching. Branching is one of the areas of CVS that just hasn't clicked for me, yet. If it's not too much trouble, could someone explain in just a couple of sentences what branching would buy me in this case? It might help me understand better what that feature is really useful for...

Thanks!

···

--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis

"I use octal until I get to 8, and then I switch to decimal."

5

Sean O'Dell wrote:

···

On Thursday 26 August 2004 21:33, Jamis Buck wrote:

I just finished rewriting Copland, almost from the ground up. I'll be
announcing the new version soon(ish), but I need to get it into CVS.
Now, there's already an existing implementation of Copland in CVS, but
I'd (obviously) like to replace it with the new version.

What is the best way to go about this? Right now, I'm leaning towards
doing a "cvs delete" on the existing implementation, and then checking
in the new implementation on top of it. Thus, the existing version
history is maintained, etc. Is there a better way to do this?

Don't try and do too much through CVS; it's a massive pain to reorganize a project through CVS. Instead, edit the CVS repository directly.

Well, mucking with the CVS repository directly isn't really an option, since I don't have direct access to the RubyForge machines. :frowning: If this really were the difference between v1 and v2 I might bug Tom about reorganizing my repo, but since its not, I think I'll just go with the tag-and-delete option.

- Jamis

--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis

"I use octal until I get to 8, and then I switch to decimal."

6

Austin Ziegler wrote:

I would tag the existing version -- and perhaps even branch it. All of
my programs and libraries are tagged and branched on major
releases (e.g., X.0.0 or X.Y.0). A notable exception is Ruwiki
0.8.0; it will not be branched until 0.8.1 becuase of some known large
changes that I want to carry forward to 0.9 even with planned
bugfixes.

At any rate, tag and branch copland as it stands. Then, do a CVS
delete on those files that no longer exist in copland. After adding
the new files, update, then tag and branch again.

-austin

Thanks for the advice, Austin. I'm familiar with tagging, but I guess I
better just bite the bullet and read up on branching. Branching is one
of the areas of CVS that just hasn't clicked for me, yet. If it's not
too much trouble, could someone explain in just a couple of sentences
what branching would buy me in this case? It might help me understand
better what that feature is really useful for...

Say you have a product called 'foo' and release version 1.0. For the next
few months, you keep working on fixes and new features. You release
version 1.1. Then a critical bug report comes in against 1.0. You can't
(necessarily) just say "upgrade to 1.1" -- that might not be an option for
the client. You need to fix their problem against the 1.0 code base.

So you create a branch at 1.0 (against the tag 'v1_0' for instance), and
fix the bug. You tag this code base 'v1_0_1' and release 1.0.1. Future
bug fixes are made against this branch and, if applicable, committed also
to the trunk.

Ruby works this way. Work on 1.8 is carried out on the 'ruby_1_8' branch.
Work on 1.9 is committed to the trunk (CVS HEAD, as it's also known).

Your "product" is copland. You can call your branch 'copland-old' or
whatever you like, and continue on your merry way in the trunk.

Branching is a PITA, but sometimes it's unavoidable. Subversion has a
more elegant implementation of it than CVS, I think. Everything else
probably does too.

Probably the best resource for you is http://cvsbook.red-bean.com.

Cheers,
Gavin

7

"Jamis Buck" <jgb3@email.byu.edu> schrieb im Newsbeitrag
news:412EC252.4060408@email.byu.edu...

Austin Ziegler wrote:

> I would tag the existing version -- and perhaps even branch it. All
> of my programs and libraries are tagged and branched on major
> releases (e.g., X.0.0 or X.Y.0). A notable exception is Ruwiki
> 0.8.0; it will not be branched until 0.8.1 becuase of some known
> large changes that I want to carry forward to 0.9 even with planned
> bugfixes.
>
> At any rate, tag and branch copland as it stands. Then, do a CVS
> delete on those files that no longer exist in copland. After adding
> the new files, update, then tag and branch again.
>
> -austin

Thanks for the advice, Austin. I'm familiar with tagging, but I guess I
better just bite the bullet and read up on branching.

You don't need to branch until you really need the branch. Example: you
release the tagged version. You checked in the new version. Now for some
reason you need to fix a bug in the tagged version. *That's* the moment
when you need to branch. Checkout the tagged version, create the branch,
make the changes to fix the bug and check them in (on the branch).

Kind regards

    robert

8

If you use a linux desktop, you might try Cervisia. I don't use it for
day-to-day work, but whenever I've had to do major restructuring to a
repository that I had no shell access to, it really helped. It's a GUI so it
really helps you see what is what and where everything is, and when you
delete something, it not only removes the file, it issues the CVS remove
command. It has saved me a lot of headache a couple times.

Sean O'Dell

···

On Friday 27 August 2004 10:19, Jamis Buck wrote:

Sean O'Dell wrote:
> On Thursday 26 August 2004 21:33, Jamis Buck wrote:
>>I just finished rewriting Copland, almost from the ground up. I'll be
>>announcing the new version soon(ish), but I need to get it into CVS.
>>Now, there's already an existing implementation of Copland in CVS, but
>>I'd (obviously) like to replace it with the new version.
>>
>>What is the best way to go about this? Right now, I'm leaning towards
>>doing a "cvs delete" on the existing implementation, and then checking
>>in the new implementation on top of it. Thus, the existing version
>>history is maintained, etc. Is there a better way to do this?
>
> Don't try and do too much through CVS; it's a massive pain to reorganize
> a project through CVS. Instead, edit the CVS repository directly.

Well, mucking with the CVS repository directly isn't really an option,
since I don't have direct access to the RubyForge machines. :frowning: If this
really were the difference between v1 and v2 I might bug Tom about
reorganizing my repo, but since its not, I think I'll just go with the
tag-and-delete option.

9

I'd be happy to help if you change your mind... it only takes a minute
for me to go in and do some mv commands... no problemo.

Yours,

Tom

···

On Fri, 2004-08-27 at 13:19, Jamis Buck wrote:

Well, mucking with the CVS repository directly isn't really an option,
since I don't have direct access to the RubyForge machines. :frowning: If this
really were the difference between v1 and v2 I might bug Tom about
reorganizing my repo, but since its not, I think I'll just go with the
tag-and-delete option.

10

Robert Klemme wrote:

"Jamis Buck" <jgb3@email.byu.edu> schrieb im Newsbeitrag
news:412EC252.4060408@email.byu.edu...

Austin Ziegler wrote:

I would tag the existing version -- and perhaps even branch it. All
of my programs and libraries are tagged and branched on major
releases (e.g., X.0.0 or X.Y.0). A notable exception is Ruwiki
0.8.0; it will not be branched until 0.8.1 becuase of some known
large changes that I want to carry forward to 0.9 even with planned
bugfixes.

At any rate, tag and branch copland as it stands. Then, do a CVS
delete on those files that no longer exist in copland. After adding
the new files, update, then tag and branch again.

-austin

Thanks for the advice, Austin. I'm familiar with tagging, but I guess I
better just bite the bullet and read up on branching.

You don't need to branch until you really need the branch. Example: you
release the tagged version. You checked in the new version. Now for some
reason you need to fix a bug in the tagged version. *That's* the moment
when you need to branch. Checkout the tagged version, create the branch,
make the changes to fix the bug and check them in (on the branch).

Thanks Gavin and Robert. Your comments, together with Austin's use-case and some reading of my own, have greatly helped my understanding on branching.

I've already been tagging my releases, so I think I'll take Robert's advice and only branch when I have to.

Next step: check in the new copland impl. :slight_smile: Then I get to rewrite the copland manual... To bad you can't really write a program that writes your manuals for you. :wink:

···

--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis

"I use octal until I get to 8, and then I switch to decimal."

11

Sean O'Dell wrote:

···

On Friday 27 August 2004 10:19, Jamis Buck wrote:

Sean O'Dell wrote:

On Thursday 26 August 2004 21:33, Jamis Buck wrote:

I just finished rewriting Copland, almost from the ground up. I'll be
announcing the new version soon(ish), but I need to get it into CVS.
Now, there's already an existing implementation of Copland in CVS, but
I'd (obviously) like to replace it with the new version.

What is the best way to go about this? Right now, I'm leaning towards
doing a "cvs delete" on the existing implementation, and then checking
in the new implementation on top of it. Thus, the existing version
history is maintained, etc. Is there a better way to do this?

Don't try and do too much through CVS; it's a massive pain to reorganize
a project through CVS. Instead, edit the CVS repository directly.

Well, mucking with the CVS repository directly isn't really an option,
since I don't have direct access to the RubyForge machines. :frowning: If this
really were the difference between v1 and v2 I might bug Tom about
reorganizing my repo, but since its not, I think I'll just go with the
tag-and-delete option.

If you use a linux desktop, you might try Cervisia. I don't use it for day-to-day work, but whenever I've had to do major restructuring to a repository that I had no shell access to, it really helped. It's a GUI so it really helps you see what is what and where everything is, and when you delete something, it not only removes the file, it issues the CVS remove command. It has saved me a lot of headache a couple times.

Thanks for the tip -- I may just do that. :slight_smile:

--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis

"I use octal until I get to 8, and then I switch to decimal."

12

Tom Copeland wrote:

···

On Fri, 2004-08-27 at 13:19, Jamis Buck wrote:

Well, mucking with the CVS repository directly isn't really an option, since I don't have direct access to the RubyForge machines. :frowning: If this really were the difference between v1 and v2 I might bug Tom about reorganizing my repo, but since its not, I think I'll just go with the tag-and-delete option.

I'd be happy to help if you change your mind... it only takes a minute
for me to go in and do some mv commands... no problemo.

Thanks, Tom. I really appreciate the offer. I think, though, that I'll try the tag-and-delete approach this time around. I'd rather keep it all in the same CVS module for now, since it's still a pre-1.0 release of the product.

Thanks again!

- Jamis

--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis

"I use octal until I get to 8, and then I switch to decimal."

13

I thought you said the user wouldn't see much change. Why the manual
rewrite?

Gavin

···

On Saturday, August 28, 2004, 12:13:18 AM, Jamis wrote:

Next step: check in the new copland impl. :slight_smile: Then I get to rewrite the
copland manual... To bad you can't really write a program that writes
your manuals for you. :wink:

14

Cool, no problemo...

Tom

···

On Fri, 2004-08-27 at 13:38, Jamis Buck wrote:

> I'd be happy to help if you change your mind... it only takes a minute
> for me to go in and do some mv commands... no problemo.
>

Thanks, Tom. I really appreciate the offer. I think, though, that I'll
try the tag-and-delete approach this time around. I'd rather keep it all
in the same CVS module for now, since it's still a pre-1.0 release of
the product.

Thanks again!

15

Gavin Sinclair wrote:

Next step: check in the new copland impl. :slight_smile: Then I get to rewrite the
copland manual... To bad you can't really write a program that writes
your manuals for you. :wink:

I thought you said the user wouldn't see much change. Why the manual
rewrite?

Gavin

"Rewrite" was probably too strong a word. I mostly just need to fix terminology changes and rework some of the tutorials.

For those that are interested, here is a list of some of the most user-visible (and non-backwards-compatible) changes coming in the next version of Copland:

   - the term "module" was confusing, given Ruby's conflicting use of the term. Thus, functional groupings of services and configuration data are now called "packages."

   - The registry is no longer a Singleton class. This makes it MUCH easier to unit test, and much friendlier to platforms like WEBrick that may run multiple unrelated processes in the same interpreter. However, this also breaks existing programs, since the interface for initializing a Copland registry is now different than before.

   - Related to the last bullet point: various options may now be passed to the registry when it is constructed. You can now specify different names for your package descriptor files if you prefer.

   - The infrastructure now exists for descriptor files in formats other than YAML. Thus, if someone REALLY wants an XML-based descriptor format, it should be possible to implement that processor and plug it right into Copland with a minimum of mess.

   - The service-point format in the package descriptor files has changed slightly: instead of 'create-instance' and 'invoke-factory' (borrowed directly from HiveMind), there is now a single 'implementor' element. This makes it easier to remember and less prone to errors.

   - Schemas are easier to write, and are radically different from previous versions (which used HiveMind's digester-based approach). The new approach is cleaner and takes advantage of more of Ruby's "dynamicity" (if that's really a word).

   - Configuration points may now define schemas as well, which describe the valid format of the contributions they accept. More work remains to be done on this, but it's a start.

Those are the highlights. HUGE refactorings occurred under the covers, as I think anyone comparing the old and new implementations will quickly discover. I'm hoping to be able to work on getting all the documentation together this weekend, in which case you can expect a new release early next week.

···

On Saturday, August 28, 2004, 12:13:18 AM, Jamis wrote:

--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis

"I use octal until I get to 8, and then I switch to decimal."

16

Excellent. I was enjoying reading the manual just yesterday. It
sounds like several of these changes will make it easier to understand
overall.

Cheers,
Gavin

···

On Saturday, August 28, 2004, 2:11:34 AM, Jamis wrote:

Gavin Sinclair wrote:

On Saturday, August 28, 2004, 12:13:18 AM, Jamis wrote:

Next step: check in the new copland impl. :slight_smile: Then I get to rewrite the
copland manual... To bad you can't really write a program that writes
your manuals for you. :wink:

I thought you said the user wouldn't see much change. Why the manual
rewrite?

Gavin

"Rewrite" was probably too strong a word. I mostly just need to fix
terminology changes and rework some of the tutorials.

For those that are interested, here is a list of some of the most
user-visible (and non-backwards-compatible) changes coming in the next
version of Copland:

[...................]

17

Gavin Sinclair wrote:

···

On Saturday, August 28, 2004, 2:11:34 AM, Jamis wrote:

For those that are interested, here is a list of some of the most user-visible (and non-backwards-compatible) changes coming in the next
version of Copland:

[...................]

Excellent. I was enjoying reading the manual just yesterday. It
sounds like several of these changes will make it easier to understand
overall.

I sure hope so. I think "understanding" is the biggest barrier-to-entry for dependency-injection/inversion-of-control. Hopefully my RubyConf presentation can help to answer people's questions about it, too. *crosses fingers*

--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis

"I use octal until I get to 8, and then I switch to decimal."