Dolphin small group easy source control...

Has any one implemented a truly easy approach to small group development in
Dolphin?  I am thinking of something like easy image syncing.

I have been using STS, and it makes group development in Dolphin doable.  I
can version packages, and load them into different images.  However STS is
not quite as seamless as I would like.  The only way to know that a package
has changes is the little triangle (which is reset if a package is saved).
There is no way to tell what changes I have made in the image versus the
last versioned package (one has to version before they can compare).  There
is no easy way of versioning all changed packages.  There is no easy way of
syncing an image with a source repository.  If there are changes in the same
package on two images I don't think there is an easy way to merge the
changes, one has to do it manually.  Feel free to give me some pointers if I
am missing anything here.  This all seems to add a bit of overhead, and I am
worried that I will loose code because I forget to do something.  I have
nothing against versioning, it definitely has its place, but I would like a
less formal way of sharing code.  I don't want to have to version and import
3 packages into my image and then have to do the same for the other image
just to make some changes to an intern's code on my computer.  I want to
sync the images, make the changes, and then sync the images again.

I would love the idea of something like a shared image, though I don't think
that is easily doable, so I will lower my expectations a bit.  I want to set
an intern to work on another computer while I continue to work on my
computer.  I want to easily merge our changes at any point in the day.  I
want to import his code in my image, and send my code to his image.  I want
to be alerted to any conflicts, though I suspect we can avoid stepping on
each others' toes in most cases.  Does anyone currently do anything like
this now?  Does anyone else find this appealing, or am I just misguided? ;)

My ideas:

1.) I could take an approach somewhat like Ian's Chunk Browser and use the
change log.  I could maintain the index of the last merge and import the
last representation of every element (prompting on conflicts).  I think this
could really work.

2.) Another approach would be for me to log all changes to my own
repository, and then sync images with the repository.  The benefit would be
less text parsing, and I could store more context info like a time stamp
with each method.

I think I like the first idea at this point, it would be the fastest way to
a useable solution with less overhead.

Any thoughts?
Chris

Chris,

> 1.) I could take an approach somewhat like Ian's Chunk Browser and use the
> change log.  I could maintain the index of the last merge and import the
> last representation of every element (prompting on conflicts).  I think
this
> could really work.
>
> 2.) Another approach would be for me to log all changes to my own
> repository, and then sync images with the repository.  The benefit would
be
> less text parsing, and I could store more context info like a time stamp
> with each method.

You might find it easier to merge the two concepts.  You can add comment to
the change log whenever you like so every method/class/resource change could
easily be preceded by a chunk giving date, time, who made the change,
package version &etc. If you also add chunks when a merge is done then it
shouldn't be too difficult to create a tool that could scan two (or more)
change logs and produce a list of multi-person changes along with a file-in
of the final versions.

NB - "it shouldn't be" :-)

Ian

Cristopher,

with STS you *can* tell what changes you have made versus the last versioned
package.

Select a changed package in the Package Browser, right click for the context
menu and select option 'Compare with...'. Now select an edition in the
repository and a changes browser window will open.

Otherwise, I think some improvements could be made in STS which would
automate merge process, etc. Next version.

Best regards,

David


"Christopher J. Demers" <[hidden email]> wrote in
message news:asut33$v2cfq$[hidden email]...
> Has any one implemented a truly easy approach to small group development
in
> Dolphin?  I am thinking of something like easy image syncing.
>
> I have been using STS, and it makes group development in Dolphin doable.
I
> can version packages, and load them into different images.  However STS is
> not quite as seamless as I would like.  The only way to know that a
package
> has changes is the little triangle (which is reset if a package is saved).
> There is no way to tell what changes I have made in the image versus the
> last versioned package (one has to version before they can compare).
There
> is no easy way of versioning all changed packages.  There is no easy way
of
> syncing an image with a source repository.  If there are changes in the
same
> package on two images I don't think there is an easy way to merge the
> changes, one has to do it manually.  Feel free to give me some pointers if
I
> am missing anything here.  This all seems to add a bit of overhead, and I
am
> worried that I will loose code because I forget to do something.  I have
> nothing against versioning, it definitely has its place, but I would like
a
> less formal way of sharing code.  I don't want to have to version and
import
> 3 packages into my image and then have to do the same for the other image
> just to make some changes to an intern's code on my computer.  I want to
> sync the images, make the changes, and then sync the images again.
>
> I would love the idea of something like a shared image, though I don't
think
> that is easily doable, so I will lower my expectations a bit.  I want to
set
> an intern to work on another computer while I continue to work on my
> computer.  I want to easily merge our changes at any point in the day.  I
> want to import his code in my image, and send my code to his image.  I
want
> to be alerted to any conflicts, though I suspect we can avoid stepping on
> each others' toes in most cases.  Does anyone currently do anything like
> this now?  Does anyone else find this appealing, or am I just misguided?
;)
>
> My ideas:
>
> 1.) I could take an approach somewhat like Ian's Chunk Browser and use the
> change log.  I could maintain the index of the last merge and import the
> last representation of every element (prompting on conflicts).  I think
this
> could really work.
>
> 2.) Another approach would be for me to log all changes to my own
> repository, and then sync images with the repository.  The benefit would
be
> less text parsing, and I could store more context info like a time stamp
> with each method.
>
> I think I like the first idea at this point, it would be the fastest way
to
> a useable solution with less overhead.
>
> Any thoughts?
> Chris
>
>
>

"David Gorisek" <[hidden email]> wrote in message
news:[hidden email]...
>
> with STS you *can* tell what changes you have made versus the last
versioned
> package.

You are right, thanks for the tip.  I do like STS, it has made multi-image
development doable for me.  Without it things would be much worse.

> Otherwise, I think some improvements could be made in STS which would
> automate merge process, etc. Next version.

I am not sure if what I am looking for (syncing code informally outside of
versioning) even fits in the scope of STS.  Of course I would love any
features that make my life easier. ;)

There does not seem to be much interest in what I proposed in my post.
Perhaps informal source syncing is not of interest to many people.

Chris

"Ian Bartholomew" <[hidden email]> wrote in message
news:P6II9.61$1I3.45482@stones...
> You might find it easier to merge the two concepts.  You can add comment
to
> the change log whenever you like so every method/class/resource change
could
> easily be preceded by a chunk giving date, time, who made the change,
> package version &etc. If you also add chunks when a merge is done then it
> shouldn't be too difficult to create a tool that could scan two (or more)
> change logs and produce a list of multi-person changes along with a
file-in
> of the final versions.

Thanks for the ideas.  I think I will defer on the idea of adding to the
change log for now (I certainly can in the future, but for now I don't think
I _need_ the time stamps except for conflict resolution assistance).  I did
find that the change log had no package information.  However I came up with
an approach of getting this information out of the image.  For now I am just
trying to do the simplest thing possible.  At the moment I am only
interested in syncing two images.  In the future there might be more.

How would you feel about me developing an add-on for your Chunk Browser
tool?  The Chunk Browser has some excellent change log parsing code that
would save me a great deal of work.  If I ever released it (not sure if any
one else would want it) I would release a package that required your Goodie
as a prerequisite (to be obtained separately).  Of course you would get
complete credit for the parser code.  Any thoughts?

Chris

Chris,

> Thanks for the ideas.  I think I will defer on the idea of adding to the
> change log for now (I certainly can in the future, but for now I don't
> think I _need_ the time stamps except for conflict resolution assistance).

I've have occasionally wondered about the usefulness of having time stamps
(for certain chunk types anyway) in the change log but, as you say, it isn't
something that there seems a real need for.  The positional relationship
between individual chunks is more important.

>                          I did
> find that the change log had no package information.  However I came up
> with an approach of getting this information out of the image.

The version 5 change log now has information about packages that are being
loaded but not about the adding/reorganising of objects to packages within
the image. It might be an useful addition though...

> How would you feel about me developing an add-on for your Chunk Browser
> tool?  []
> Any thoughts?

Feel free.  Let me know if you want me to make any changes to make it
easier - it's not something I allowed for when I designed (to use a totally
inaccurate word) the original application.

Ian