[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Paperclips-discuss] Paperclips Bugs
From: |
Steven J. Owens |
Subject: |
Re: [Paperclips-discuss] Paperclips Bugs |
Date: |
Mon, 25 Jun 2001 16:33:23 -0400 (EDT) |
> >>> Steven J. Owens <address@hidden> 25-Jun-01 7:04:41 PM >>>
>
> So should I move up to HEAD as well?
>
> Probably.
I'll play with it tonight. Right now, the alpha release is
compiled and working, so I'll play with it.
> paperclips makes cleanly (though it still complains
> about getopt).
>
> What's the complaint? I don't get one.
It complains "class Getopt is public, should be declared in a
file named Getopt.java" and the same for LongOpt.
> I've thought of different schemes for this -
> using two different repositories, branching
> and merging on a daily basis, etc.
>
> That would be very complicated....
Yeah, which is why I haven't done anything on it yet. I'm kinda
hoping the subversion guys will come up with something before I
finally get around to it...
> but with a hacked client it might work.
Well, I like the simplicity of the tags approach, but I realized
a gotcha; CVS won't let you commit over newer code, so if developer A
commits an in-progress during the day, when developer B goes to try
it, he'll get conflicts. I can think of ways to fix this, but then
you have the problem of trying to get the rollback, etc. Hm. On
second thought I'm beginning to think a either a painless branch/merge
client or local repositories make more sense.
> However, if I just manage my repository a bit better this shouldn't
> be a problem /8->
Yeah, but I still want in-progress commits. Every now and then I
get to a point where I realize I've gone down a dead-end and I'd
really like to go back to where I was an hour ago...
Steven J. Owens
address@hidden