directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject RE: [VOTE] Retrofitting the old code base with snickers
Date Wed, 23 Jun 2004 08:55:18 GMT
On Tue, 2004-06-22 at 22:25, ????? wrote:
> I'm not a voting member, but it sounds like a good idea.

Not at all you're vote counts.  Feel free to join in and vote any time.


> -----Original Message-----
> From: Alex Karasulu [] 
> Sent: Wednesday, June 23, 2004 11:13 AM
> To:
> Subject: [VOTE] Retrofitting the old code base with snickers
> Hi,
> Noel, Jeff and I have had several conversations offline about retrofitting the old code
base initially imported into the SVN repository, with the new snickers LDAP/BER codec.  The
goal/intention is to have a working hybrid of the new Eve and the older code base early rather
than waiting for all the features of Eve to arrive in one big bang.  This hybrid will be free
of any snacc dependencies and hence be suitable for release once the project has left the
incubator.  It will allow those interested to fire up the server and kick the tires. 
> Offline I've begun splicing in the parts of Eve that will allow the operation of the
old code base using snickers.  I did this just to start getting a feel for how difficult it
would be.  Soon I noticed that the changes were well worth keeping. 
> I could not find a workable point within the SVN repository where I could easily salvage
the old code base.  Plus I already made really drastic changes that well were made fast, and
late at night.  There were some changes that I made without properly tracking them :-(.  Hunting
down the changes and merging them with the new ones would have been more work than using what
I had.  If no one objects, I would like to add this code into the subversion repository as
a detached branch of the eve subproject.  I'm thinking of going this route rather than creating
a new subproject under directory for a few reasons:
>  o this is Eve server code
>  o it has been branched but the branch cannot be merged to the trunk  o maintenance on
it will cease asa the trunk is viable  o the branch will be considered a maintenance branch
if we 
>    release - no further development will take place outside of 
>    minor bug fixes
> The one pitfall with this approach is that there is a history disconnect on these files.
 They were previously imported with history from the CVS repository into SVN.  So we
have all the changes that have been made by commiters in the past.  We would be starting the
history again from scratch at another point in the repository.  Sure this makes hunting down
changes that happened ages ago a bit more difficult, but this is a tradeoff.  I don't intend
to support this branch for more than a few months.  As soon the server in the trunk can be
fired up with the backend currently in the sandbox to service requests, I will vote to freeze
work on the branch.
> I know this not the cleanest route but its the fastest immediate route I have for a very
short term solution.  If a release occurs from this branch we will not branch it but just
keep it as the maintenance branch which we would have had if we forked from the trunk.
> So if all approve the idea I'd like to keep rolling to show that Eve can come up without
snacc4j dependencies; so that we have a server once we exit the incubator; and so we can have
a little fun too.
> [ ] Scratch the whole idea and continue with Eve in trunk
> [ ] Create defunct Eve branch using initial pre-subversion code base
> Until this vote commenses I will be adding the files to subversion as a private branch
I can work in.  If the community decides to scratch the idea I will remove the checkins immediately.
 So please, please, don't get offended if you see commits going by - I'm just working on a
flaky new solaris 10 box and don't want to loose what changes I've already made.
> Thanks,
> Alex

View raw message