Re: [platform-cvs-dev] Checking out files not intended for a project

[Michael Valenta <Michael_Valenta@xxxxxxxxxx>]

Thomas,

That is a result of how we fetch the
contents. To get ride of the tag, you will need to set the tag field of
the resource sync info to null. The easiest way to do this is as follows
(this is off the top of my head so may not be 100% correct):

ResourceSyncInfo info = cvsFile.getSyncInfo();
MutableResourceSyncInfo mutable = info.cloneMutable();
mutable.setTag(null);
cvsFile.setSyncInfo(info);

Michael

Thomas Hallgren <thomas@xxxxxxx>
Sent by: platform-cvs-dev-bounces@xxxxxxxxxxx

27/12/2006 10:05 AM

Please respond to
"Eclipse CVS Integration developers list."        <platform-cvs-dev@xxxxxxxxxxx>

To	"Eclipse CVS Integration developers list." <platform-cvs-dev@xxxxxxxxxxx>
cc
Subject	Re: [platform-cvs-dev] Checking out files not intended for a project

I've encountered yet another problem with my sandbox
approach. The same 
files for which I needed a special workaround in order to get correct 
timestamps are also annotated with a sticky tag. In the explorer, the 
file typically show up like this:

plugin.xml 1.56 1.56 (ASCII -kkv)

i.e. the version is repeated twice. I've tried using both null and 
CVSTag.DEFAULT when I create the sandbox but I get the same result.

What could be the cause of this problem and how can I get rid of this 
sticky tag?

Kind Regards,
Thomas Hallgren


Thomas Hallgren wrote:
> Jepp. Works like a charm. Thanks again.
>
> - thomas
>
> Michael Valenta wrote:
>>
>> The timestamp should be provided by the checkout so I'm not sure
why 
>> it would be null. As a workaround, you could assign the timestamp
of 
>> the file on disk to the sync info (i.e. create a 
>> MutableResourceSyncInfo for the ResourceSyncInfo and set the 
>> timeatamp) before writing the sync info to disk. This will work
but 
>> will make the timestamp on disk differ from the timestamp on the
>> server. Having the tiemstamp match that of the server is really
only 
>> a convenience for the user so I think this would be acceptable.
>>
>> Michael
>
> _______________________________________________
> platform-cvs-dev mailing list
> platform-cvs-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-cvs-dev

_______________________________________________
platform-cvs-dev mailing list
platform-cvs-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-cvs-dev